|
DEUTSCHE VERSION |
|
 |
| Links | | | Forums | | | Comments | | | Report news |
|
| Chat | | | Polls | | | Newsticker | | | Archive |
|
| amiga-news.de Forum > Amiga, AmigaOS 4 > "Virtueller RAM Speicher" als Partition oder in einer Datei | [ - Search - New posts - Register - Login - ] |
| 1 2 3 4 -5- | [ - Post reply - ] |
|
2007-12-05, 23:38 h TetiSoft Posts: 197 User |
@whose: > Partieller Speicherschutz z.B. knackt garantiert das Konzept einiger > Programme Also es gibt mehrere Arten Speicherschutz in OS4: Die Zeropage ist lese- und schreibgeschützt bis auf Adresse 4 (AbsExecBase). Zugriff auf "nirgendwo" (0xDEADBEEF usw) startet den GrimReaper (so eine Art Enforcer mit der Option ein CrashLog zu speichern). Zugriff auf freien Speicher kann einen Hit auslösen, muß aber nicht, es hängt davon ab ob der Speicher schonmal verwendet wurde und ob das ein großer oder kleiner Block war usw. PPC-Code ist schreibgeschützt. Read-only Daten von PPC-Programmen sind schreibgeschützt (.rodata Sektionen usw in ELF-Dateien). Stacküberlauf löst meist auch einen Hit aus weil eine Guard-Page verwendet wird. 68k CODE, DATA und BSS Segmente sind aus Kompatibilitätsgründen NICHT schreibgeschützt! Es gibt zu viele 68k Programme die z.B. Stringkonstanten im CODE Segment haben und diese dann auch noch zur Laufzeit ändern wollen, sie dürfen das nach wie vor. [ - Answer - Quote - Direct link - ] |
|
2007-12-05, 23:47 h TetiSoft Posts: 197 User |
@MaikG: > >Nimm zum Beispiel mal die Geschichte mit den "Zählschleifen". > >Du ignorierst hartnäckigst die (wirklich guten) Argumente, > >die Dir aufzeigen, daß Deine Annahmen darüber irgendwo im Gebüsch > >landen, sobald Deine Programme mal auf einem anders getakteten, > >ansonsten gleichartigen Prozessor laufen. > Aber andere irgnorieren das es die eine Möglichkeit > der genannten war und ich von Anfang an gesagt habe das > sowas keine saubere Programmierung ist. Diese blöde Idee mit den Zählschleifen oder NOPs kam von mir, mir war auf die Schnelle kein besseres Beispiel für JIT-Unverträglichkeit eingefallen, und ich denke wir sind uns alle einig daß es schon auf 68k eh nicht gehen würde und können die Diskussion darüber also friedlich beeenden, ok? :-) [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 00:21 h whose Posts: 2156 User |
Zitat: Einige davon habe ich ja kennengelernt  Die Sache mit dem out of bounds laufenden Quellzeiger bzw. -Block beim inflate war gemein  Grüße -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ Dieser Beitrag wurde von whose am 06.12.2007 um 00:24 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 09:28 h Solar Posts: 3680 User |
Zitat: Und damit können wir die Diskussion, glaube ich, abschließen.  [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 10:02 h MaikG Posts: 5172 User |
>Alles andere funktioniert definitiv nicht 100%ig kompatibel, weil es >zwangsläufig Unterschiede geben muß, wenn man an irgendeiner Stelle >ansetzt, um Verbesserungen zu machen. Nehmen wir den Patch BlaceWCP, er ändert, macht schneller - beeinflusst aber kein mir bekanntes Programm/Spiel. Oder bei CGX, was im prinzip eine große Sammlung von Patches ist. AGA geht trotzdem weiterhin. Das geht schon damit los, daß man den 68K-Emulator "wirtschaftlich" betrachtet nicht so bauen kann, daß er alle möglichen 68K-Modelle 100% emuliert. Die meisten möchten nämlich (darunter auch DU), daß der auf der OS4-Hardware so schnell wie möglich läuft. Damit hast Du schon einen Unterschied, da hört es aber noch längst nicht auf. Es reicht völlig den 68060 zu emulieren. Fehlende Instuktionen ersetzt WHDLoad oder die 68060.library. Für 000/020/030/040 only befehle gäbe es dann keinen grund. Damit wäre der jetzige JIT noch etwas schneller. 040 ist bei Winuae daher, das dieser weniger Instruktions als kleiner Prozessoren hat auch die schnellste Einstellung. >Tja, das ging auch nur, weil man am Unterbau sehr wenig verändert >hat. Speicherschutz z.B. hat OS3.x gar nicht, nicht einmal teilweise. Intern nicht. Aber ich persönlich würde es nicht als wichtig bezeichnen. Als Programmier zeigt mir Cyberguard wenn ich mist baue. Ich würde den fehler jetzt auch korregieren wenn ich wüsste das es nicht so schlimm ist - denn das OS hat ja Speicherschutz... >Das bedeutet? Wenn es den Ersatz nicht sofort bei Erscheinen gibt, >taugts nix? Dann müßten wir heute alle ne Turnhalle im Garten stehen >haben, in der ein ENIAC aufgebaut ist. Bedenken, ebend in der Anfangsphase. Erstmal gibt es keinen oder wenig ersatz. Dann überlegt man sich als Programmier, gehe ich das Risiko jetzt ein? Benutze ich ein OS, was nicht alles bietet was ich brauche, in der Hoffnung das es sich mal ändern wird? Zitat: >Partieller Speicherschutz z.B. knackt garantiert das Konzept einiger >Programme (darunter WHD) WHD hatte schon Speicherschutz als es noch kein OS4 gab. WHD ist kompatibel und verhindert effektiv evtl. Hits in die OS Umgebung. Nur dank Fehlen MMU Support fällt dies weg. >Den PPC und dessen MMU sowie das Speicherschutz-System von OS4 >beachtest Du bei Deiner Argumentation nämlich nicht. Richig. Fakt ist aber es geht nicht. Du zeigst aber auf einen Ansatzpunkt, in wie fern WHD abgepasst werden könnte. >OS4 hat eigene Verwendung für die MMU, sie ist also nicht mehr >"frei", wie das unter OS3.x der Fall ist. Die MMU wird durchaus für z.B. Cyberquard unter OS3.9 verwendet, womit WHD kein Problem hat. Gab es nicht sogar eine mmu.library für das Management, so das zwischen mehreren Programmen die die MMU benutzen keine Probleme gibt? >Und den hast Du unter OS4. Ja, aber dafür laufen einige Programme nicht, und E-UAE auf Classic... >Sogar die VLab läuft unter OS4 (siehe Liste). Das was du als VLab liesst ist ein normaler Bild-digitalisier. Die VLab-Motion digitalisiert Videos. Korregiere mich wenn tatsächlich die "Motion" kürzlich der Liste hinzugefügt wurde. [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 10:46 h whose Posts: 2156 User |
Zitat: In diesen Bereichen ist "Kompatibilität" allerdings auch weit einfacher machbar. Was daran zu erkennen ist, daß AGA unter OS4/MOS weiterhin benutzbar ist. Allerdings nicht in sehr speziellen Anwendungsgebieten wie z.B. "Hardwarebanging am OS vorbei". Zitat: Oh Himmel... was ist so schwer daran zu verstehen, daß der Sinn von OS4/MOS nicht ist, einzig eine schnellere Umgebung für z.B. WHDLoad bereitzustellen? Der Sinn von OS4/MOS ist, sich von der vom Hersteller quasi totgesagten Plattform 68K zu lösen, denn AmigaOS vor OS4/MOS war dem 68K "auf den Leib geschneidert". Und Du hast die Beschreibung des OS4 JIT nicht gelesen. Er emuliert einen 68040 (bis auf wenige Instruktionen und hat keine MMU), meldet aber aus Kompatibilitätsgründen einen 68020. Der JIT an sich ist wirklich schnell genug. Starte ein für 040 optimiertes Programm darauf und Du wirst sehen, daß es funktioniert (sofern es sauber geschrieben wurde). Zitat: Genau deswegen hat OS4 das nun ja auch intern. Es ist aber etwas arg viel erwartet, daß es die "sechstausend" unterschiedlichen Arten, so etwas unter OS3.x zu implementieren, 100% kompatibel nachahmt. Zitat: Was will der Autor damit sagen? Also, wenn Du unter OS4 Mist baust in Deinem Programm, dann sagt Dir das nun der GrimReaper. Zitat: Du siehst das Problem, erkennst es aber nicht wirklich, sonst hätte es diese Diskussion gar nicht erst gegeben. Richtig, Programme, die nicht ganz hasenrein geschrieben worden sind, müßten auf die neuen Gegebenheiten angepaßt werden. Gut, bei vielen Programmen ist das nicht mehr machbar, aber solche Fälle gab es auch schon beim Wechsel von OS1.3 nach OS2.x. Und auch dort hat sich das anfängliche Geschrei nach einer Weile gelegt. Wozu also jetzt schon wieder sinnlos lamentieren? Zitat: Wie wäre es, wenn Du die testest und der Liste hinzufügst (sofern Du eine hast)? Ich weiß ja nicht, wie gut Du Dich über die "Marktsituation" für diese Karte informiert hast, aber ich habe festgestellt, daß die so etwas wie die blaue Mauritius unter den Videokarten ist. Extrem selten. Wieso sollten ausgerechnet die OS4-Betatester so eine Karte besitzen? Weißt Du, es ist schon etwas anderes, als Entwicklungsteam Zugang zu verbreitet vorhandener Althardware zu haben, als als selbiges möglicherweise jahrelang nach Uralt-Hardware zu suchen und einen Release zu verschieben, weil so ein Teil nicht wirtschaftlich aufzutreiben ist. -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2007-12-06, 11:00 h TetiSoft Posts: 197 User |
@MaikG: > Es reicht völlig den 68060 zu emulieren. Fehlende Instuktionen > ersetzt WHDLoad oder die 68060.library. > Für 000/020/030/040 only befehle gäbe es dann keinen grund. > Damit wäre der jetzige JIT noch etwas schneller. Fehlende 68k Instruktionen durch die 68k 68060.library nachzubilden ist höchstwahrscheinlich nicht so schnell wie sie einfach nicht fehlen zu lassen und in PPC-Code zu übersetzen. Die Mathe-Bibliotheken die ja nur von 68k Programmen gebraucht werden sind mittlerweile größtenteils auch kein 68k FPU-Code mehr sondern PPC FPU-Code weils schneller ist. > >OS4 hat eigene Verwendung für die MMU, sie ist also nicht mehr > >"frei", wie das unter OS3.x der Fall ist. > > Die MMU wird durchaus für z.B. Cyberquard unter OS3.9 verwendet, > womit WHD kein Problem hat. > > Gab es nicht sogar eine mmu.library für das Management, so > das zwischen mehreren Programmen die die MMU benutzen keine Probleme > gibt? Die lief nicht auf A1200 und wurde nicht mit OS3 mitgeliefert weil sie nie Bestandteil von AmigaOS war. Ich hatte bereits gesagt daß die MMU beim Amiga immer optional war, kein API im OS existiert, und die Anzahl der 68k-MMU verwendenden Programme die unter OS4 noch sinnvoll einsetzbar wären gegen NULL tendiert. Wahrscheinlich ist sie sogar tatsächlich 0. Wenn Du immer noch unbedingt eine emulierte 68k MMU haben willst mußt Du wahrscheinlich selbst eine programmieren. Ich sehe keine Möglichkeit einen der OS4-Emulator-Entwickler davon zu überzeugen es zu tun. [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 11:15 h Solar Posts: 3680 User |
Zitat: Und dann kommt der nächste an und schreit, weil die Emulation auf seinem Classic ja gar nicht die Geschwindigkeit eines 68060 erreicht und deswegen das Timing alter Software ja nicht mehr passen würde... > Speicherschutz z.B. hat OS3.x gar nicht, nicht einmal teilweise. > Intern nicht. Aber ich persönlich würde es nicht als wichtig > bezeichnen. Als Programmier... ...hast Du entsprechende Tools zur Verfügung, mit der Du alle Zugriffsfehler finden kannst, die bei Deinen Tests auftreten. Speicherschutz ist aber kein "Tool" für Programmierer, sondern ein "Feature" für den Anwender - um dessen System zu schützen, wenn ein Programmierer einen Fehler mal nicht gefunden hat (was öfter vorkommt als man manchmal denkt, insbesondere bei Hobbycodern). Zitat: ROI (return on investment). Geh hin, schreibe einen besseren JIT, "and the world will beat a path to your door" (Ralph Waldo Emmerson). Zitat: Du blickst gerade in die richtige Richtung: Problem von WHD, nicht von OS4. Zitat: Du scheinst relativ wenig davon zu verstehen, wie die MMU von einem speichergeschützten OS verwendet wird. Es gibt keine Möglichkeit, eine "Mitbenutzung" der MMU zu ermöglichen, ohne den kompletten Speicherschutz des OS auszuhebeln. (Es sei denn, der Speicherschutz beim PPC sei wesentlich anders implementiert als auf x86 oder Sparc.) Zitat: Man muß ein Ei zerschlagen, um ein Omlett zuzubereiten. [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 12:33 h Holger Posts: 8116 User |
Zitat:Jenseits heißt 68020, 68030, 68040 oder 68060. Eben nicht 68000. Also auch kein Degrader, um 68000 Software auszuführen, denn von 68000-Software wollten wir hier nicht reden, und ein Degrader ist kein Selbstzweck. Schließlich diskutierst Du ja gerade über die so sinnvolle Frage, ob nun ein 68020 oder ein 68060 emuliert werden soll. Zitat:Und dass solche Software seit dem 68020, eigentlich schon seit dem Erscheinen von 68010- und 14MHz 68000-Beschleunigern nicht mehr funktioniert. Ob das Flag in der Exec-Base einen 68060 ausweist oder einen 68020, spielt für solche Software keine Rolle. Zitat:Aha! Du siehst also ein, dass das Timing in einer Emulation (vor allem mit JIT) nicht korrekt ist. Was diskutierst Du dann hier überhaupt so sinnlos rum?! Du hast übrigens offensichtlich den Witz dabei nicht kapiert. Du darfst gerne jede beliebige Software benutzen, meinethalben eine, von der Du meinst, dass sie die Taktfrequenz auf einem echten Amiga richtig errechnet: Wie Dir vielleicht noch nicht aufgefallen ist, gibt es beim UAE überhaupt keine "richtige Taktfrequenz". Die einzige einstellbare exakte Taktfrequenz ist "Match A500 Speed", die logischerweise nur beim emulierten 68000 (und somit ohne JIT) funktioniert. Alle anderen Prozessoreinstellungen besitzen überhaupt keine Möglichkeit einer justierbaren Taktfrequenz und somit auch kein korrektes Timing im Sinne der Prozessorgeschwindigkeit. Wenn es auch nur ein relevantes Programm gäbe, dass nicht für den A500 geschrieben wurde (Siehe "Match A500 Speed") und von einer bestimmten Prozessorgeschwindigkeit ausgeht, hätte sich schon jemand beschwert. Zitat:So so. Du rüstest auf PPC und AOS4 auf, nur um damit eine Türsprechanlage zu betreiben? Na, dafür wirst Du wohl auch eine angepasste AOS4-Version Deiner Zählschleifen implementieren können... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 12:43 h Holger Posts: 8116 User |
Zitat:Gibt es eine Möglichkeit für 68k-Programme, unter AOS4 eine strengere Kontrolle für sich selbst zu beantragen? (Eine Art Speicherzugriffs-FSK, sozusagen) Zitat:Oder es nimmt die Meldung beim Wort und bringt eine Fehlermeldung, dass es einen 68040 benötigt. Zitat:Nun ja, den meisten Programmen dürfte es weniger darum gehen, die MMU direkt programmieren zu können, sondern bestimmte Features zu verwenden. Sei es, beim Zugriff auf einen bestimmten Speicherbereich (in ihrer eigenen Anwendung) informiert zu werden, oder darauf aufbauend, virtueller Speicher oder Memory Mapped IO oder eben, um die Regeln für den eigenen Speicher noch zu verschärfen. Wenn eine Bibliothek das anbieten würde (was andere Betriebssysteme auch anbieten), sehe ich da keine Probleme. Zitat:Hmm, also die 6xx_Reihe dürfte noch keine Virtualisierungsfunktionen besitzen mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 13:04 h TetiSoft Posts: 197 User |
Zitat:Nein. Ein Programm was das machen würde sollte besser auf OS4 getestet werden bevor man es in Umlauf bringt, und dann kann man ja gleich eine PPC-Version testen wo es den Unterschied zwischen .data und .rodata Sektionen sowieso gibt. Die Funktionen in OS4 welche die MMU verwenden sind von 68k-Programmen auch gar nicht aufrufbar. Zitat:Ein Programmierer der weiß was er tut kann Funktionen aufrufenZitat:Nun ja, den meisten Programmen dürfte es weniger darum gehen, die MMU direkt programmieren zu können, sondern bestimmte Features zu verwenden. Sei es, beim Zugriff auf einen bestimmten Speicherbereich (in ihrer eigenen Anwendung) informiert zu werden, oder darauf aufbauend, virtueller Speicher oder Memory Mapped IO oder eben, um die Regeln für den eigenen Speicher noch zu verschärfen. Wenn eine Bibliothek das anbieten würde (was andere Betriebssysteme auch anbieten), sehe ich da keine Probleme. um z.B. Speicherbereiche schreibzuschützen oder Exception-Handler, Task-Trap-Handler usw. installieren. [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 13:34 h Holger Posts: 8116 User |
Zitat:Hmm, ich dachte eher daran, dass man vielleicht auch ohne AOS4 so viele Plattformen wie möglich unterstützen will, und eine Operation, die man unter 68k sonst via mmu durchführen würde, beim Erkennen von AOS4 ans OS delegiert. Nun ja, in den meisten Fällen läuft ein sauberes Programm ohne diesen Schutz ja auch fast so gut wie mit... Zitat:Aber das kann man nicht via mmu.library zur Verfügung stellen, da 68k-Software diese Funktionen nicht aufrufen kann, richtig? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 14:21 h ZeroG Posts: 1487 User |
@Holger:Zitat:Man könnte eine native mmu.library mit 68k Einsprungtabelle machen. Diese könnte dann auf die MMU-Funktionen von Exec zugreifen. Ob das allerdings Sinn macht kann ich nicht beurteilen. [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 15:12 h TetiSoft Posts: 197 User |
@Holger:Zitat:So rein gefühlsmäßig wäre Speicherschutz für Code und als "const" deklarierte Daten auch bei 68k-Programmen wichtiger als daß ein 68k-Programm selbst MMU-Funktionen aufrufen kann. Es würde sich anbieten, neue Hunk-Typen wie "ROCODE" und "RODATA" einzuführen, aber die existierenden 68k-kompatiblen Betriebssysteme alle zu erweitern oder sich überhaupt erstmal zu einigen ist vermutlich nicht machbar. HUNK-Format suxx... Wenn ich an die OS3-Keymaps im HUNK-Format zurückdenke bin ich froh daß das hinter uns liegt. Zitat:Viele neue Funktionen in OS4 sind ganz normal in den 68k-Sprungtabellen der jeweiligen Bibliotheken eingetragen, aber soweit ich mich erinnere nicht die neuen Funktionen von exec incl. MMU Interface oder expansion incl. PCI Interface. 68k TaskTraps werden mittlerweile unterstützt IIRC. [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 18:09 h MaikG Posts: 5172 User |
>Wie wäre es, wenn Du die testest und der Liste hinzufügst >(sofern Du eine hast)? Kann man das? Erstmal muss ich nur wichtigere Probleme mit OS4 lösen. <>Ich weiß ja nicht, wie gut Du Dich über die "Marktsituation" für >diese Karte informiert hast, aber ich habe festgestellt, >daß die so etwas wie die blaue Mauritius unter den Videokarten ist. Quatsch, das teil hab ich für 50 Euro bei Ebay gekauft. Da waren haufenweise damals davon drin. Eine Subway ist vielleicht selten geworden. >Speicherschutz ist aber kein "Tool" für Programmierer, >sondern ein "Feature" für den Anwender - um dessen System >zu schützen, wenn ein Programmierer einen Fehler mal nicht gefunden >hat (was öfter vorkommt als man manchmal denkt, insbesondere >bei Hobbycodern). Ich lach mich tot. Den OS4 Speicherschutz hab ich mittlerweile gesehen. 4 Programme, eins davon ein OS4 eigenes Programm haben OS4 zum vollständigen absturz gebracht. >So so. Du rüstest auf PPC und AOS4 auf, nur um damit eine >Türsprechanlage zu betreiben? Na, dafür wirst Du wohl auch eine >angepasste AOS4-Version Deiner Zählschleifen implementieren können... Nein, die läuft über ein anderen Computer. Nein, kann ich nicht anpassen, es sei denn es gibt ein zusatz Flag das mir sagt das der Prozi emuliert wird. [ - Answer - Quote - Direct link - ] |
|
2007-12-06, 20:02 h TetiSoft Posts: 197 User |
@MaikG: > Nein, kann ich nicht > anpassen, es sei denn es gibt ein zusatz Flag das mir sagt > das der Prozi emuliert wird. Zitat: [ - Answer - Quote - Direct link - ] |
|
2007-12-07, 12:22 h Holger Posts: 8116 User |
Zitat:Um das ging es ja in erster Linie. Spezielle, weitergehende Logik macht bei 68k-Programmen nicht viel Sinn, da die anderen 68k-Systeme ja auch nichts vergleichbares anbieten. Zitat:Ich glaube auch nicht, dass eine Erweiterung von AOS3.x von Hyperion gewollt wäre. Solche Backports wurden auch für andere Features bislang nicht in Erwägung gezogen. Andersherum ist eine Erweiterung des Hunk-Formats für (neue) 68k-Programme auch nicht gewollt, wenn ein solches Programm AOS4 benötigt, also auch für ppc übersetzt werden könnte. Deshalb sind neue Hunk-Typen keine gute Wahl. Eine vom 68k-Programm aufrufbare Funktion oder ein Flag in einem bislang unter AOS3.x unbenutzten Bereich wäre die bessere Wahl. Ich würde sowieso begrüßen, wenn es eine solche Standard-Möglichkeit gäbe, ein paar Meta-Informationen über das Programm abzulegen. In der Art: Flag-Bit: 0 - Aufruf aus der Shell unterstützt 1 - Aufruf von der Workbench unterstützt 2 - Code-Hunk darf schreibgeschützt werden 3 - Resident möglich (keine Veränderung/Verlust der Information durchs Dateisystem mehr) 4-6 - 000 Anwendung, 001 Library, 010 Device, 011 DOS-Handler, 100, KeyMap, 101 Font, etc. Man könnte sich noch andere Meta-Informationen vorstellen, benötigte Stack-Größe, Sachen, die eigentlich nicht verloren gehen sollten, wenn das Icon nicht mitkopiert wird (bzw. eigentlich nicht vom Endanwender manipulierbar sein sollten) oder auch zwingend benötigte Libraries als vorab-Information, um gar nicht erst das Programm starten zu müssen, nur um zu erfahren, dass etwas fehlt. Wenn man bei dem alten Prinzip bleibt, das solche essentiellen Informationen im Icon gespeichert werden, kann man natürlich auch einfach ein neues ToolType einführen "ProtectCode". Das wäre am einfachsten. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2007-12-07, 12:30 h Solar Posts: 3680 User |
Zitat: Wie dick muß man Sarkasmus eigentlich auftragen, damit er bei Dir ankommt? [ - Answer - Quote - Direct link - ] |
|
2007-12-12, 20:57 h hacky Posts: 349 User |
Zitat: Leider ist dem nicht so ! Der TCP/IP Stack stürzt mit dem OS4 device der RTL8029 und Mediator gnadenlos ab ! Hätte ich das vorher gewusst, hätte ich mir schon vor Wochen eine Ariadne besorgt... *** gelöscht, bitte nicht zu illegalen Handlungen aufrufen (cg) *** -- A600, A1200 PPC240/060 Desktop, A4000 Tower PPC233/060, CD32, SX64, C64 und VC20 im Einsatz. [ Dieser Beitrag wurde von cgutjahr am 13.12.2007 um 04:31 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2007-12-13, 16:39 h cgutjahr Posts: 2783 [Administrator] |
Zitat:http://www.amiga-news.de/de/news/AN-2007-12-00042-DE.html -- Gutjahrs Amiga Seiten [ - Answer - Quote - Direct link - ] |
| 1 2 3 4 -5- | [ - Post reply - ] |
| amiga-news.de Forum > Amiga, AmigaOS 4 > "Virtueller RAM Speicher" als Partition oder in einer Datei | [ - Search - New posts - Register - Login - ] |
|
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |
|
,