|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
|
uho
Nutzer
23.02.2012, 12:16 Uhr [ - Direktlink - ] |
Thema: Hilfe ! Uhr legt A4000D komplett lahm !
Brett: Amiga, AmigaOS 4 @dandy: Da war mir richtig reparieren lieber als eine solch aufwendige Lösung - bin nur alle paar Tage/Wochen im Netz (meist Zeitverschwendung); booten (und damit die Uhrzeit auslesen) muß ich aber einige (beim proggen: viele) Male am Tag... Gruß uho |
|||||
|
uho
Nutzer
23.02.2012, 12:12 Uhr [ - Direktlink - ] |
Thema: Hilfe ! Uhr legt A4000D komplett lahm !
Brett: Amiga, AmigaOS 4 @Musicman: Solche Leute habe ich gerne: Vier Jahre lang nix beitragen und dann auch noch - statt sich über den Erfolg zu freuen - mäkeln, wenn sie die Details ungezählter Arbeitsstunden nicht auf dem Silbertablett serviert bekommen ! uho |
|||||
|
uho
Nutzer
19.02.2012, 16:58 Uhr [ - Direktlink - ] |
Thema: CyberVisionPPC-Umschalter streikt / Hilfe/Ersatz gesucht
Brett: Amiga, AmigaOS 4 Zitat: Habe ich nicht mehr finden können - war wohl eher am Rande erwähnt oder ist verlorengegangen. Allerdings suche ich auch eher die robuste Ausführung: Das Micronik Power M-disk (extern) 1.76MB. Dieses solide verarbeitete beige HD-LW arbeitet ohne Treiber an sämtlichen Amigas ab OS 2.x. Also wer das noch hat: HER DAMIT ! Gruß uho |
|||||
|
uho
Nutzer
19.02.2012, 16:35 Uhr [ - Direktlink - ] |
Thema: CyberVisionPPC-Umschalter streikt / Hilfe/Ersatz gesucht
Brett: Amiga, AmigaOS 4 @Maniac: Kenne ich nicht; könntest Du mir den Link/die Bauanleitung nennen ? Lieber wäre mir natürlich der von "Multimedia & Design" - da weiß ich, daß er funzt und eine eine sehr gute Bildqualität sichert... Gruß uho |
|||||
|
uho
Nutzer
19.02.2012, 16:31 Uhr [ - Direktlink - ] |
Thema: Hilfe ! Uhr legt A4000D komplett lahm !
Brett: Amiga, AmigaOS 4 HEUREKA - ich hab' ihn gefunden !! (Den Fehler in der Echtzeituhr meines A4000D. Nachdem ich mich nach langer Zeit nochmals zwei Tage mit Oszi, Hirnschmalz und Schaltplänen befaßt habe, konnte ich den fehlerhaften IC [es war übrigens nicht die eigentliche Echtzeituhr] finden und wechseln.) Jetzt habe ich ein beinahe komplettes Ersatzsystem für meinen Arbeitsplatz (Amiga, Turbo- u. GraKa, hochwertigen Röhren-Monitor). Das Einzige, was ich nicht doppelt habe, ist der elektronische Monitorumschalter von Multimedia & Design. Und nun ratet mal, was seit einigen Wochen anfängt kaputtzugehen... Gruß uho |
|||||
|
uho
Nutzer
14.02.2012, 16:01 Uhr [ - Direktlink - ] |
Thema: CyberVisionPPC-Umschalter streikt / Hilfe/Ersatz gesucht
Brett: Amiga, AmigaOS 4 @thomas: Hallo Thomas, erst eine so schnelle Reaktion und nun gar keine ? Oder packst Du schon das Kabel für mich ein ? Wäre ja zu schön... Gruß uho |
|||||
|
uho
Nutzer
06.02.2012, 17:27 Uhr [ - Direktlink - ] |
Thema: CyberVisionPPC-Umschalter streikt / Hilfe/Ersatz gesucht
Brett: Amiga, AmigaOS 4 @thomas: Hallo Thomas, erstmal danke für die schnelle und präzise Antwort. Leider zerstob die geweckte Hoffnung sehr schnell: Der Macher des Umschalters hat keine Umschalter mehr, fertigt auch keine, hat den Schaltplan nicht mehr und kann auch kein Kabel zur Überbrückung des Umschalters fertigen, da dies über eine reine Verdrahtung der Stecker hinausgeht... Um den Amiga im Fall der Fälle wenigstens noch mit der GraKa nutzen zu können, wäre ich an einem entsprechenden Kabel (CybervisionPPC -> 15pol. VGA) interesiert. Allerdings kann ich mangels Kreditkarte (und Browserfähigkeiten) nicht an der genannten Quelle bestellen. Würdest Du mir evtl. so ein Kabel bestellen und schicken ? Damit wäre mir schon sehr geholfen ! Gruß uho |
|||||
|
uho
Nutzer
05.02.2012, 16:30 Uhr [ - Direktlink - ] |
Thema: CyberVisionPPC-Umschalter streikt / Hilfe/Ersatz gesucht
Brett: Amiga, AmigaOS 4 Hallo, ich verwende einen elektronischen Monitorumschalter, um zwischen meiner CyberVisionPPC und AGA (manuell) umzuschalten. Dieser schwächelt leider zusehends, d.h. nach dem Booten dauert es Sekunden..Minuten, bis der GraKa-Bildschirm angezeigt wird. Ursache ist eine zu niedrige Spannung am Jumper (der dafür offen sein muß), die bei reichlich 1V beginnt und sich erst nach und nach auf die (wahrscheinlich) korrekten 3V einpegelt (Kondensatoren sind OK). Schlimm an daran drei Dinge: - Die verwendeten ICs sind abgeschliffen (und wahrscheinlich Marke "selbstgebrannt"), so daß sie nicht zu ersetzen sind und die Schaltung nicht nachzuvollziehen ist. - Der Umschalter läßt sich nicht umgehen, da aus der GraKa nur ein Flachbandkabel kommt (dessen Belegung mir unbekannt ist), welches sich nicht direkt mit einem PC-Monitor verbinden läßt. - Ich wüßte nicht, woher Ersatz zu bekommen wäre (insbes. da mir die genaue Produktbezeichnung / der Hersteller unbekannt sind). Nach einigen Recherchen _vermute_ ich, daß es sich um Item #3799 im http://www.bboah.de handelt. Wer kann Reparaturtips / Schaltungsunterlagen geben bzw. mir einen funktionierenden Umschalter verkaufen (EBay hat nix) ? Baldige Hilfe wäre wünschenswert, denn ohne Bild selst sich selbst ein Amiga nur ganz, ganz schwer bedienen - von Forenbeiträgen ganz zu schweigen... Gruß uho P.S.: Vor längerer Zeit hatte ich über ein externes HD-Disk-LW berichtet (leider ohne hilfreiche Resonanz), welches innerhalb weniger Wochen komplett den Geist aufgab. Ursache waren wohl ebenfalls selbstgebrannte ICs mit über- schrittenem Verfallsdatum. War übrigens kein Bastelteil (wie vermutet), sondern von einer US-Firma zusammengefriemelt (docs/rview/DellDX9.txt). Wenn da noch jemand 'ne Idee hätte... |
|||||
|
uho
Nutzer
21.04.2011, 09:19 Uhr [ - Direktlink - ] |
Thema: Disketten-Laufwerk dreht durch
Brett: Amiga, AmigaOS 4 @Thore: Hallo Thore, zu 1) Ich teste eigtl. immer mehrere Varianten, um das eigl. defekte Gerät zu bestimmen. zu 2) Steht ganz oben. IMMER NOCH ! zu 4) Glaubst Du wirklich, daß ich hier die relativ lange Fehler- beschreibung wiederhole, nur damit Du nicht auf "suchen" klicken mußt ?! Wie gesagt, ich bin mir sicher, daß der Fehler in der Elektronik des Laufwerks zu suchen ist und hatte halt auf einen Experten auf diesem Gebiet gehofft. Gruß uho |
|||||
|
uho
Nutzer
17.04.2011, 10:46 Uhr [ - Direktlink - ] |
Thema: Disketten-Laufwerk dreht durch
Brett: Amiga, AmigaOS 4 Hallo, danke für Eure Mühe. Leider nicht so hilfreich wie gehofft.. @DaxB: Habe auch nochmal MCP 'runtergeladen (btw, riesiges Prog für die paar Patches) obwohl ich mir sehr sicher war, daß man damit nicht die Drehzahl ändern kann: Wäre ja auch zu schön mittels Software aus einem DD- ein HD-LW zu machen... @Thore: Laufwerkstyp steht oben - das andere LW ist (erstmal) wieder montiert. Muß erstmal das "durchdrehende" LW reparieren, da die Meßtechnik (zu)viel auf dem Computertisch beansprucht. Trivialitäten wie Schmutz entfernen etc. verstehen sich von selbst. Das ext. LW wird an 'nem intakten 1200er betrieben. Der 4000er mit der vergeßlichen Uhr steht (aus diesem Grunde) seit Jahren 'rum. Ich empfehle den sehr ausführlichen Fehlerbericht nachzulesen... Gruß uho |
|||||
|
uho
Nutzer
15.04.2011, 10:30 Uhr [ - Direktlink - ] |
Thema: Disketten-Laufwerk dreht durch
Brett: Amiga, AmigaOS 4 Hallo noch verbliebene Amiga-Fans, wiedermal knifflige Fragen, diesmal zu Disketten-Laufwerken. Mittlerweile besitze ich zwei defekte Diskettenlaufwerke (extern, DD) vom Typ SV 702 (Hersteller: Datalux). Obwohl äußerlich identisch und vom selben Hersteller, wurden intern sehr unterschiedliche Laufwerke verbaut. Eines funktioniert mit der Workbench einwandfrei, in XCopy aber nicht. Dort wird zwar das Vorhandensein erkannt und auch Laufwerks- und Steppermotor können bewegt werden. Aber stets bricht XCopy mit der Meldung "Keine Diskette in DF1:" ab. Fehlt sicherlich ein Signal. Was müßte ich da verändern, um dieses LW komplett funktionsfähig zu machen ? Das andere LW ging früher, erkennt mittlerweile keine Disks mehr (auch nicht die selbst formatierten). Die Mechanik scheint OK zu sein. Mittlerweile habe ich heraufgefunden, warum: Es dreht sich viermal so schnell wie es sollte (1200 U/min). Das Indexsignal kommt aber an und wird auch bis zum Amiga weitergeleitet. Sollte damit nicht auch die Geschwindigkeit reguliert werden ? Wo könnte der Fehler liegen ? Im LW selber sind zwei Platinen, dahinter noch eine für die Amiga-Anpassung. Typbezeichnung ist Epson SMD 400. Wer weiß Rat ? Btw, ich suche immer noch ein ext. HD-LW sowie Rat zu meiner vergeßlichen Echtzeituhr im A4000D (siehe Artikel von vor Jahren :-(( ). Gruß uho |
|||||
|
uho
Nutzer
02.08.2010, 19:49 Uhr [ - Direktlink - ] |
Thema: Scart + LCD TV flimmert
Brett: Amiga, AmigaOS 4 Hallo DaDude, hatte schon bei verschiedenen Amigas/Fernsehern den Fall, daß dunkle Streifen langsam von oben nach unten scrollten. Einfache, stets wirksame Gegenmaßnahme war das Abtrennen des Antennenkabels. Wahrscheinlich gibt's da irgendeine Schwebung... Gruß uho |
|||||
|
uho
Nutzer
24.07.2010, 10:55 Uhr [ - Direktlink - ] |
Thema: Sch... PPC hat den Geist aufgegeben :-(
Brett: Amiga, AmigaOS 4 Hallo, bei mir warens bei ähnlichen Symptomen die Lötstellen des 68060er-Sockels. Kannst ja mal meinen Beitrag übers Hoffen&Bangen :-) lesen... Gruß uho |
|||||
|
uho
Nutzer
22.12.2009, 17:01 Uhr [ - Direktlink - ] |
Thema: Widerspenstige A500+ - Erweiterung
Brett: Amiga, AmigaOS 4 Hallo, (Goja: Danke für den Tip, waren aber keine Jumper drauf) nach der hiesigen Ratlosigkeit habe ich mich zu härteren Schritten entschlossen: Zuerst habe icb auf EBay eine entsprechende Erweiterung bestellt. So bekam ich für wenig Geld eine hochwertige Erweiterung von Micronik, die auch fehlerfrei funktionierte. Somit konnte ein Defekt an der Computerhardware ausgeschlossen werden. Nachdem ich nochmals sämtliche Verbindungen kontrolliert, die Platine mehrfach gesäubert, sämtliche Kontakte in der Buchse mühsam nachgebogen (ging schon ziemlich leicht zu stecken) sowie alle Leiterzüge und Widerstandsnetzwerke durchgemessen hatte, entschloß ich mich schließlich zum Wechseln eines Speicher/ICs. Das Auslöten aus der zweilagigen Platine ist ziemlich heikel, ging aber letzlich ohne Schäden über die Bühne. Ein Test ergab kein eindeutiges Bild. Da es unwahrscheinlich war, daß der ausgetauschte IC auf dieselbe Art defekt war wie der neue, vermutete ich, daß das Testprogramm den Steckplatz seitenverkehrt anzeigte (btw, tut es nicht). Also wechselte ich auch noch den Speicherchip auf der gegenüberliegenden Seite - mit demselben "Erfolg"... Nun war ich erstmal ratlos. Dann versuchte ich, während des Speichertests mittels eines angefeuchteten Fingers gezielt Fehler zu provozieren: Zuerst ergab sich kein einheitliches Bild. Doch dann geschah das Weihnachtswunder: An einer bestimmten Stelle war der Test auf einmal fehlerfrei ! Und dies war reproduzierbar ! Also ersetzte ich meinen Finger durch einen Tupfer, um Erdungs- und kapazitive/induktive Effekte auszuschließen. Und siehe da: es ging. Bis ich dann die zwei Pins herausgefunden hatte, die ich mit einem Widerstand passender Größe verbinden mußte, vergingen wieder einige Tage. Dann gab's im Speichertest keinerlei Probleme mehr. Ich wollte mich schon freuen und bootete WB2.04 (und manchmal auch per Softkick KS1.3). Bei beiden gab es aber sporadische Abstürze und andere Ungereimtheiten. Also vermutete ich, daß ich vielleicht benachbarte Speicheradressen durch die Überbrückung als eine Zelle angesprochen und so defekte Zellen gar nicht ausgelesen wurden. Das könnte dem Testprogramm u.U. entgehen, da es zwar mit verschiedenen, aber innerhalb eines Blocks identischen Werten testet, z.B. 0xAAAAAAAA über 256K. Also schrieb ich ein kleines Assemblerprogramm, daß auch mit verschiedenen Werten testet und dabei benachbarte Adressen stets mit unterschiedlichen Bytes beschreibt. Und siehe da: Keine Fehler ! Also schnell nochmal die Micronik-Erweiterung 'rein, vorher aber einen IC 'rausgezogen (dort sind sie gesockelt) - prompt wird ein Fehler gemeldet. Also ging auch mein Programm zuverlässig... Und da fiel es mir plötzlich wie Bits & Bytes aus den Haaren: Vor 15 Jahren hatte ich doch meinen Original-A500+ mit Kick 3.1 ausgestattet. Und warum ? Weil unter Kick 2.04 - und meines Wissens nach nur dort - ein kritischer Fehler auftritt, der zu ständigen Abstürzen der ram.lib, Prüfsummenfehlern der Rad: nach dem Booten und ähnlichen Speicherfehlern führt. Also testete ich einige Spiele, die das OS abschalten (Apydia, Lotus II), die wunderbar liefen, sowie Railroad Tycoon, welches 1MB benötigt. Letzteres schaltet das OS zwar nicht ab, verwaltet aber seine Resourcen selber am OS vorbei (was man daran merkt, daß es als einziges mir bekanntes Programm auf Klicks reagiert, die für einen anderen Screen bestimmt sind). Somit ist nur zu sagen: Ende gut, alles gut. Aus einem geplanten (und bitter nötigen) Akku/Wechsel wurde eine Wochenlange Odysee, bei der der arme Erweiterungsschacht hunderte Steckvorgänge über sich ergehen lassen musste. Zusammenfassen läßt sich sagen: - Sämtliche Lötstellen, Leiterbahnen und Bauelemente waren intakt. - Die Platine wies einen Layoutfehler auf, der zu Fehlern in wechselnder Zahl und an verschiedenen Adressen führte. - Dieser Fehler wurde zusätzlich von einem heimtückischen Bug in den Kickstart 2.04-ROMs überlagert. - Dieser Text entstand auf besagtem A500+ :-) Tja, nun gibt es noch die Erweiterung für den A500 (ohne "+"), deren Uhr, nicht aber deren RAM erkannt wird. Und natürlich seit zwei Jahren den A4000D mit der Uhr, die zwar läuft, ihre Daten aber nicht hält... Für "sachdienliche Hinweise" gibt's zwar keine Belohnung, aber ein Dankeschön ! Gruß uho P.S.: Datenblatt zu besagten ICs wären interessant. Habe aber nur Seiten gefunden, bei denen man sich anmelden muß und/oder die Links sich im Kreis drehen... |
|||||
|
uho
Nutzer
25.11.2009, 18:05 Uhr [ - Direktlink - ] |
Thema: Widerspenstige A500+ - Erweiterung
Brett: Amiga, AmigaOS 4 Hallo zusammen, habe wiedermal ein (unlösbares ?!) Problem für Euch: (zur Erinnerung: Die Uhr im A4kD behält das Datum immer noch nicht) Hatte letztes Jahr einen A500+ eingelagert, den ich vor dem Schredder gerettet habe. Schien alles noch zu gehen. Jetzt hatte ich Zeit, ihn mal zu öffnen (war noch versiegelt!). Uhrenakku böse ausgelaufen - gewechselt & alles gereinigt: Uhr ging auf Anhieb wieder. Leider jedoch nicht die 1MB-ChipRAM-Trapdoor-Erweiterung (einzige Beschriftung: A500+ 1Meg). Mein Testprogramm (was von einer ähnlichen Erweiterung mit mehr MB stammt und auf allen Rechnern bis zum '060er sehr zuverlässig läuft) meldet diverse Fehler im RAM. Anzahl schwankt zwischen ca. sieben und sechzig, verteilt auf 1-4 ICs (8 Stück vorhanden) Reinigen und sogar Nachlöten jeder einzelnen Lötstelle sowie Ausmessen sämtlicher Leiterbahnen zeigte keine Veränderung. Anschließend den 500+ komplett zerlegt. Board (Rev.8.A.1) sieht bis auf die Stelle beim Akku sehr gut aus. Sämtliche Rückstände entfernt, alles gründlich gereinigt, sämtliche ICs gezogen und wieder eingesetzt - keine Veränderung. Test mit einer (funktionierenden) 0.5MB-Erweiterung von einem A500 zeigte keinerlei Fehler. Die A500+ - Erweiterung im A500 auch nicht (wird dort aber nur zur Hälfte erkannt). Interessanterweise habe ich seit zwei Jahren eine 0.5MB-Erweiterung, bei der ich zwar die Uhr wieder zum Laufen bringen konnte, der Speicher aber in keinem Rechner erkannt wird oder einen gelben Bildschirm ergibt. Diese Erweiterung basiert auf denselben RAM-Chips, nämlich TC514256Z-12 (je 1/8 MB ZIP-RAM). Nun überlege ich, diese zur Reparatur der A500+ - Erweiterung heranzu- ziehen. Da dies ob der vielen Pins und der dünnen Leiterbahnen eine recht heikle Sache ist und ich zudem vielleicht nur einen defekten IC gegen einen anderen austausche (und überdies nicht mit Sicherheit auszuschließen ist, daß es nicht doch am Compi liegt), wollte ich hier erstmal nachfragen: - Sind Probleme mit der Haltbarkeit der genannten ICs bekannt ? - Muß ich evtl. evtl. was Jumpern (in der beiliegenden Kurzanleitung stand davon nix) ? - Was könnte man sonst noch machen ? Wenn all dies fehlschlägt: - Verkauft mir jemand solche ICs ? - ...oder eine intakte 1MB-Erweiterung für den A500+ ? mfg uho P.S.: Habe herausgefunden, wie man die CF2IDE-Karten-Adapter von Pollin umbauen muß, daß die HD-LED beim A1200 wieder leuchtet. Nur falls das jemanden interessieren sollte. Mich hat die fehlende Zugriffskontrolle jedenfalls genervt... P.P.S.: Bin nur ab und zu "im Netz". Seid also bitte nicht allzu ungeduldig mit mir... |
|||||
|
uho
Nutzer
10.03.2009, 12:25 Uhr [ - Direktlink - ] |
Thema: And the Oscar goes to...
Brett: Amiga, AmigaOS 4 @Chritoph: Danke ! Der Link ist: http://www.amiga-news.de/forum/thread.php?id=24081&start=post&postid=243110&BoardID=1 (Beitrag von Darksun) Die Karte ist eine "normale" CyberStorm PPC (50/200 MHz). Gruß uho |
|||||
|
uho
Nutzer
09.03.2009, 17:34 Uhr [ - Direktlink - ] |
Thema: Weitere Amiga-Sichtungen
Brett: Amiga, AmigaOS 4 @Thore: Danke für die Info. Hätte da gar nicht mit einem Ergebnis gerechnet. Ob das Spiel letztlich indiziert wurde weiß ich allerdings nicht, da es während die Kamera lief noch vom "Experten" getestet wurde  Und die Zeiten, in denen Computerzeitschriften die Liste mit indizierten Spielen abdruckten, sind ja auch schon lange vorbei... Gruß uho |
|||||
|
uho
Nutzer
09.03.2009, 12:49 Uhr [ - Direktlink - ] |
Thema: Weitere Amiga-Sichtungen
Brett: Amiga, AmigaOS 4 Hallo Leute, durch Zufall habe ich gleich zweimal unser Hobby im Fernsehen entdeckt: Sichtung 1: Auf einem alten "Clarissa"-Band: Für wenige Augenblicke war da eine WB 1.3 zu sehen. In der Titelzeile stand allerdings "Fastbench Release 1.3 4372040 free memory" (aber ziemlich unscharf). Angemeldet waren "RAM Disk", "MeTV", "Sy", "Hardy", "Bench". Als Programme liefen "PuptoColours 1.0" und "CaptainVideo". Nun meine Frage: Gab es ein Programm/einen Patch namens "Fastbench" ? Die Schrift ist zwar ziemlich undeutlich, aber "F" und "W" unterscheiden sich doch ziemlich deutlich. Oder wurde hier absichtlich der Text verändert, um Schwierigkeiten mit Commodore aus dem Weg zu gehen ? Kennt jemand die anderen Programme ? Ich hatte ja damals schon immer den "Verdacht", daß der Amiga in der Serie seine Hand im Spiel hat. Die gelegentlichen Zwischenspiele am Computer haben zwar nicht Amiga-Niveau (ist auch keine Amiga-Tastatur), aber die vielen Einblendungen schon. War schließlich die Glanzzeit des Amiga und mit Genlock die einzig preiswerte semiprofesionelle Lösung... Für das "Sy" hätte ich zwei Erklärungen anzubieten: - Vertipper bei "Sys" - Es gibt einen "Sy Rosen", der "Co-Executive Producer" der Serie "Wunderbare Jahre" war - Zielgruppe könnte hier durchaus die inzwischen älteren "Clarissa"-Gucker gewesen sein. Sichtung 2: Letztens kam ein Rückblick über die Nachwendezeit. Als ein kurzer Beitrag über die Bundesprüfstelle angekündigt wurde, habe ich gleich geistesgegenwärtig den Videorekorder angeworfen (Intuition :-)) ) Und tatsächlich, nach einem kurzen Schwenk über die Flure (überall eindeutiges Gestöhne) sah man in einem Zimmer einige Frauen, die stark an "Siebziger-Jahre-Sekretärinnen" erinnerten. Diese versuchten krampfhaft das mir bis dahin unbekannte Spiel "Dogs of War" (wohl ein harmloser 2D-Shooter) zu testen. Sie scheiterten jeweils nach wenigen Sekunden, hatten aber den "Auftrag", das Spiel komplett (!!) durchzuspielen, da es sonst nicht indiziert werden könnten. Btw. könnte 'ne nette Insider-Info für Spielehersteller sein: Einfach das Ende unspielbar schwer machen :-) Der Clou war aber dann, daß die illustre Runde einen Minderjährigen beauftragte, das Spiel vor laufender Kamera zu spielen. O-Ton: "Die Prüfer können nicht prüfen, weil sie das Spiel nicht verstehen. Ein Experte muß 'ran." (hier kommt der Junge [wortwörtlich] ins Spiel.) "Und unter den prüfenden Augen zahlreicher Mitarbeiter der Bundes- prüfstelle für jugendgefährdende Schriften zeigt der Minderjährige den Mitarbeitern, wie das jugendgefährdende Spiel funktioniert. Jugendschutz im Computerzeitalter - eine gefährliche Mission." Schon eine besondere Ironie, wenn die selbsternannten "Sittenwächter" Kinder bzw. Jugendliche zu "Straftaten" anstiften... In "echt" isses natürlich noch lustiger als in 'ner textuellen Beschreibung... Gruß uho |
|||||
|
uho
Nutzer
09.03.2009, 12:44 Uhr [ - Direktlink - ] |
Thema: And the Oscar goes to...
Brett: Amiga, AmigaOS 4 Hallo, Moderator !! Gibt's jetzt 'ne Postadresse für Notfälle oder ist man tatsächlich erschossen, wenn man trotz defekten Amigas 'ne Frage hat ??? Gruß uho |
|||||
|
uho
Nutzer
22.02.2009, 22:48 Uhr [ - Direktlink - ] |
Thema: And the Oscar goes to...
Brett: Amiga, AmigaOS 4 Hallo zusammen, (ja, ich wollte zur Abwechslung auch 'mal 'ne nichtssagende Betreffzeile testen) ...Darksun ! Herzlichen Glückwunsch ! Die Academy war vom Beitrag des Produzenten Darksun angetan, der das zerstörungsfreie Nachlöten des 68060-Sockels per Präzisions-IC-Pin zum Thema hat.... Nachdem ich schon so ziemlich alle steckbaren ICs, Jumper, die Prozessorplatine und das Daughterboard entnommen und die Kontakte gereinigt hatte und dann immernoch fast jedesmal das von ??? beschriebene Dauerbooten eintrat, konnte ich den Amiga doch nochmal zum Booten bewegen und so im Forum nach entspr. Beträgen suchen. Der 68060 ging angenehm leicht aus der Fassung (ich hatte Bedenken gehabt, daß das Keramikgehäuse brechen könnte), so daß ich mir nicht erklären kann, daß gleich ein halbes Dutzend Stifte keinerlei Verbindung mehr zur Platine hatten. Von den Steckkräften kann es nicht kommen und dank Passiv-Kühlkörper und sorgsamster Behandlung über die Jahre hatten die Lötstellen eigtl. nichts auszustehen. Keine Ahnung was Phase5 da "produziert" hat... Der Tip mit dem Präzisionssockel war 'ne feine Sache. Die Stifte hatte ich sogar in Leistenform da, so daß ich da nichts opfern mußte. Nur einmal wurde es kritisch, als sich etwas Zinn zwischen dem eingesteckten Stift und dessen schmelzender Plasteumhüllung nach unten gemogelt und so zu einer ungewollten, dafür aber umso haltbareren Verbindung zum Sockel gesorgt hatte. Aber mit gefühlvollem Einsatz von Lötkolben und Bohrmaschine konnte auch dieser Pin funktionfähig erhalten werden. Danach habe ich den einzusteckenden Pin immer durch ein Stück Papirt gesteckt - nur für alle Fälle. Trotzdem eine heikle Sache, da man die meisten Lötstellen nichtmal sehen - geschweige denn evtl. Kurzschlüsse o.ä. korrigieren kann. Also habe ich an jedem Pin der Fassung leicht gewackelt und nur die wirklich losen Stifte nachgelötet. Jedenfalls scheint alles wieder zu laufen - sonst wäre dieser Beitrag auch nicht möglich. Apropos (un)möglich: Gibt es Postadresse des Forums bzw. würde sich jemand (z.B. der Moderator) bei Notfällen bereiterklären, entspr. Fragen/Antworten weiterzuleiten ? Mir ist nämlich schon immer das Problem bewußt gewesen, daß ich im Falle eines wie auch immer gearteten Hard- oder Softwareproblemes gar niemanden um Rat fragen kann... (Apropos im apropos: Das Problem mit der vergeßlichen Echtzeituhr harrt auch schon seit Monaten einer Lösung. Keiner 'ne Idee ? ) Ok, alles in allem ist dieser Schriebs wohl wieder etwas länger geworden - liegt sicher an der Schwere des Steins, die mir gestern vom Herzen geplumpst ist :-)))) Gruß uho "Drei Tage war die Freundin krank ! Jetzt bootet sie wieder - Gott sei Dank !" (frei nach Wilhelm Busch) |
|||||
|
uho
Nutzer
05.02.2009, 19:32 Uhr [ - Direktlink - ] |
Thema: A2000 bootet nicht mehr
Brett: Amiga, AmigaOS 4 Zitat: Hatte mal 'n 500er, bei dem die Kiddies wohl in der seriellen Schnittstelle mit 'nem Schraubendreher o.ä. gewerkelt hatten. Fehlerdiagnose war einfach - der entspr. Chip war regelrecht explodiert :-O Wie auch immer - hab 'nen neuen eingelötet in der Hoffung, daß nix anderes defekt war. Dann langes Gesicht: nur der von Dir beschriebene weiße Bildschirm - keine Einschaltgrafik. Bis ich darauf gekommen bin, das Disk-LW wieder anzuschließen. Ohne das wird der Selbsttest nicht abgeschlossen... (Die Reparatur war übrigens erfolgreich...) Gruß uho |
|||||
|
uho
Nutzer
16.01.2009, 16:25 Uhr [ - Direktlink - ] |
Thema: Diskettenphänomene
Brett: Amiga, AmigaOS 4 @Thore: Habe es auf '020, '030 und '060 getestet (sowohl mit als auch ohne Fast-RAM) - überall mit demselben Ergebnis. Verhält sich auch sonst nicht anders als auf einem A500 (den ich jetzt nicht extra hervorgekramt habe), so daß anzunehmen ist, daß der Bug vom Prozessortyp unabhängig ist... Gruß uho |
|||||
|
uho
Nutzer
05.01.2009, 18:48 Uhr [ - Direktlink - ] |
Thema: Diskettenphänomene
Brett: Amiga, AmigaOS 4 Hallo, die letztlich in A-News angepriesene XMas-Version hat denselben Bug, d.h. sie formatiert auch nicht wirklich. Ob zusätzlich die Bitmap falsch ist habe ich nicht getestet, da ich das Archiv vor Frust gleich wieder gelöscht habe... (jetzt teste ich erstmal die "Ändern"-Option B-) ) ...da ja außerdem Gfx & Font häßlich waren und außerdem mind. ein (kleiner) Bug hinzugfügt wurden (fehlender Doppelpunkt in der Zeitangabe) Gruß uho P.S.: Frohes 2009 ! [ Dieser Beitrag wurde von uho am 05.01.2009 um 18:53 Uhr geändert. ] |
|||||
|
uho
Nutzer
30.11.2008, 19:20 Uhr [ - Direktlink - ] |
Thema: Diskettenphänomene
Brett: Amiga, AmigaOS 4 @Thore: Hallo, wie schon ausgeführt, löscht mein XCopy die Daten auch bei einer kompletten Formatierung nicht. Man kann dann - z.B. mit AZap - die Blöcke anschauen und sieht dieselben Daten wie vorher (abgesehen von den Root- u. Bootblöcken). Nur für den Sonderfall, daß man mehr als eine Disk gleichzeitig formatiert, findet man dann tatsächlich Nullen. Ausnahme bildet da lediglich XCopy-TNG. Für mich war die Erkenntnis, daß sich nicht nur mein Original- XCopy so verhält, wichtig. Noch besser wäre ein entspr. Patch. Welche Version hast Du ? Filegröße ? Gruß uho |
|||||
|
uho
Nutzer
30.11.2008, 18:24 Uhr [ - Direktlink - ] |
Thema: Diskettenphänomene
Brett: Amiga, AmigaOS 4 Hallo, kleiner Nachtrag: Beim Stöbern in alten Disk-Beständen sind mir noch andere XCopy-Versionen untergekommen, z.B. eine Version 6.01 (lt. Gfx - ohne Versionsstring). Da diese sowohl von der Filegröße (ungepackt) als auch vom Funktionsumfang her kleiner war, ist davon auszugehen, daß es sich um eine ältere Version handelt. Die Grafik wurde ja gerne mal ausgetauscht... Diese und auch zwei andere Versionen hatten den beschriebenen Fehler, daß physikalische Schäden am Datenträger zwar bemerkt, die Bytes aber nicht verändert werden, ebenfalls. Komisch, daß diesen Fehler (heutzutage würde man ihn vielleicht als "ernstes Datenschutzproblem" titulieren) von einer (mindestens) fünfstelligen Nutzerzahl bisher niemand bemerkt hat... Gruß uho |
|||||
|
uho
Nutzer
30.11.2008, 18:21 Uhr [ - Direktlink - ] |
Thema: Schwerwiegende Bugs im "Version"-Befehl:
Brett: Amiga, AmigaOS 4 Hallo zusammen, erstmal danke für die verschiedenen Tips ! Die OS-Changes-Datei hatte ich übersehen. Normalerweise lasse ich nur Includes&Autodocs durchsuchen bzw. nehme irgendein Buch zur Hand. Die "tutorials"-Schublade ist als offizielle Quelle wohl über die Jahre in Vergessenheit geraten B). Im "User Interface Style Guide" hätte ich allerdings nicht gesucht. Hab' ich mal bei E-Bay gesehen, aber nicht mitgesteigert, da ich annahm, daß es da nur um die Anordnung von GUI-Elementen u. dgl. geht. Der "VersionWB"-Befehl ist eine sehr gute Alternative (und mit entspr. gesetzter Umgebungsvariable kriegt man auch die lästigen Requester weg ).Eine korrekte Versionsausgabe ist also keine Magie ! Das hier tatsächlich Handlungsbedarf besteht, legt schon die Existenz eines solchen Tools nahe. O-Ton des Autors: (it includes) "* All other features which AmigaDos Version has, as far as I know 8-), except for the bugs "Danke an DarkSun - das war ein wirklich heißer Tip ! Bei der Diskussion um das "V" in den Version-Strings haben wir fast aus den Augen verloren, daß sich das Commodore"-Version (39.4) sich auch bei "korrekten" Strings falsch verhält: Beispiel: reqtools.library 38.1387 code:8.RamDisk:> version libs:reqtools.library reqtools.library 38.1387 8.RamDisk:> version libs:reqtools.library file Workbench:Libs/reqtools.library 8.RamDisk:> version libs:reqtools.library file full Workbench:Libs/reqtools.library (12.05.96) 8.RamDisk:> Wie schon ganz am Anfang erwähnt (und hier leider angezweifelt) unterdrückt der Parameter "FILE" die Versionsausgabe auch hier. Stattdessen wird (sinnloserweise) der komplette Pfad ausgegeben. code:8.RamDisk:> type libs:reqtools.library opt h 0000: 000003F3 00000000 00000003 00000000 ...ó............ 0010: 00000002 00002B35 40000012 00000045 ......+5@......E 0020: 000003E9 00002B35 70FF4E75 72657174 ...é..+5p.Nureqt 0030: 6F6F6C73 2E6C6962 72617279 00726571 ools.library.req 0040: 746F6F6C 73203338 2E313338 37202831 tools 38.1387 (1 0050: 322E352E 3936290D 0A004AFC 00000032 2.5.96)...Jü...2 0060: 00000078 80260900 00000004 00000015 ...x.&.......... 0070: 00000078 E0000008 0900C000 000A0000 ...xà.....À..... 0080: 0004E000 000E0600 D0000014 0026D000 ..à.....Ð....&Ð. *** Abbruch Wie man sieht, steht die Versionsnummer allein - und trotzdem geht's nicht... Dies ist übrigens kein Einzelfall - bei keiner einzigen der achtzehn Libraries auf der WB3.1-Disk z.B. wird der Versionsstring angezeigt ! Liegt evtl. daran, daß "$VER" ebenfalls nicht vorhanden ist... Nachtrag: Version 40.1 dagegen verhält sich korrekt. Das war mir bis eben entgangen B-( . Also war der Befehl "nur" die allermeisten - aber nicht alle - Amiga-Jahre fehlerhaft... Damit hat die Sache doch noch ein (genaugenommen sogar zwei) gute Enden gefunden und ein eigenes Programm erübrigt sich - wie erhofft. Da ich mich aber schon vor dem VersionWB-Tip durch die Bits und Bytes gewühlt (mangels Masse aber noch nicht zu fragen getraut) hatte, hier noch eine Frage, für die Ihr mich wohl lynchen werdet :-) : In keiner einzigen Commo-Lib beginnen die Versionsstrings mit $VER, was einer einfachen Suche im Wege steht. Also habe ich in den RKRMs und dem Intern gelesen. In der dort aufgeführten Library-Struktur sollte der String ab Offset 24 (Zählung ab 0) beginnen. Da ich aber nicht weiß, wieviel Bytes der Linker davorschreibt (und dies sowieso von Lib zu Lib verschieden ist) und ob sonst nochwas davorsteht, habe ich versucht, einen Zeiger darauf zu finden. Und das möglichst ohne die Hunk-Struktur anlysieren zu müssen (quick-and-dirty). Da Libs, um beim Aufruf nicht zu crashen, mit moveq #0,d0 / rts (bzw. -1 statt 0) beginnen, was zu 0x70004e75 bzw. 0x70ff4e75 assembliert, sollte man sich damit - zumindest bei Libs - schonmal an der richtigen Position befinden. (Ansonsten wird diese Methode sicher in die Hose gehen, da ja praktisch jedes Prog diese Kombination irgendwo enthält). Durch Intuition .-) habe ich herausgefunden, daß ab dieser Adresse ab Offset 22 ein LW mit dem Offset des Versionsstrings der Lib, gerechnet ab moveq, steht. Habe es bisher noch nicht gecoded, manuelle Auszählung hat aber bei mehreren Libs geklappt... Stimmt aber nicht mit Offset 24 aus der Struktur für lib_IDString überein (nach moveq/rts ergibt sich noch ein Offset von 18). Welche sechs Bytes habe ich da nicht beachtet ? Gibt es eine zuverlässigere "Startposition" für die Offsetberechnung als die moveq/rts-Suche ? (Ich könnte auch lib_Revision/Version verwenden - das Problem, den richtigen Startpunkt zu finden, bleibt aber.) Wie gesagt, hat jetzt nur noch akademischen Wert - aber dazulernen kann man immer. Schöner wäre natürlich gewesen, wenn sich die Commo-Leute auf _eine_ Art von Versionsstring hätten einigen können. Dafür hätte noch nichtmal das Betriebbsystem geändert werden müssen - eine entsprechende Richtlinie in den RKRMs hätte genügt, um die einfache Suche nach $VER unabhängig vom Filetyp zu ermöglichen (was ja der Sinn einer derartigen Kennung sein sollte)... Soweit erstmal uho |
|||||
|
uho
Nutzer
24.11.2008, 20:36 Uhr [ - Direktlink - ] |
Thema: Schwerwiegende Bugs im "Version"-Befehl:
Brett: Amiga, AmigaOS 4 @Holger: Zitat: Das ist und bleibt falsch - egal wie oft Du es hinschreibst ! Wozu habe ich eigtl. das Commo-Handbuch zitiert ?! Die Option FILE - so sie funktioniert - ist nur bei Mehrdeutigkeiten erforderlich: Also falls man keinen Pfad angibt UND das File im aktuellen Verzeichnis UND außerdem im Speicher steht. Kannste auch leicht überprüfen: Wenn nur die ersten beiden Bedingungen zutreffen, sollte nach DEINER Theorie "Objekt nicht gefunden" erscheinen - da ja ohne die Option angebl. nur der Speicher geprüft wird. Tatsächlich wird aber die Datei verarbeitet - wie man nicht nur an der Ausgabe sieht, sondern auch mit SnoopDOS nachprüfen kann... Zitat: Diese Meinung kannst Du natürlich gerne vertreten. Aber wenn Dich die Rechner anderer Leute nicht interessieren - was zum Teufel machst Du dann hier ? Zitat: Warum ich mir die Mühe mache, entsprechende Beiträge zu schreiben, habe ich bereits ausführlich dargelegt. Ansonsten wäre es ja viel einfacher und schneller gewesen einfach mit dem proggen anzufangen, stimmt's ? Zitat: Zu der Sache mit dem "V" vor der Versionsnummer habe ich im Guru-Book folgendes gefunden: "This version string should be specified in the following format: code:dc.b '$VER: name version (date)',13,10,0 "Although the version string may be terminated by any of the three control characters used above, and 'name', 'version' and 'date' may comprise almost any sequence of printable characters..." Es folgen Beispiele. Kurz gesagt: Nach "$VER: " ist fast alles erlaubt. Annahmen über die genaue Zeichenabfolge sind reine Spekulation ! Es sieht vielmehr so aus, daß "Version" hier ein bischen zuviel des Guten tut - und prompt scheitert. Im Übrigen ist das mit dem "V" auch kein "Ausrutscher" eines Autors - auch in folgenden Libraries habe ich es gefunden: CBR0, DLTA, HUFF, (HFMN), IDEA, MASH, (RAKE), SHRI (): statt "V" steht "Version" Obwohl die obenstehende Erläuterung aus dem Abschnitt "Libraries" stammt, haben viele Libraries den "klassischen" Versionstring nicht. Hier muß man wohl - wie von DieterG angeregt - über den Aufbau der Lib gehen. Das muß ich erst noch ausknobeln B-) . Zitat: Wie schon vorher erwähnt, hättest Du die entspr. Versionen auch wirklich testen/kundgeben sollen. Dann wären wir schneller zum Ziel gekommen, anstatt Äpfel mit Birnen zu vergleichen. Ansonsten hatte Dein letzter Beitrag sogar mal Substanz. Weiter so. Gruß uho |
|||||
|
uho
Nutzer
19.11.2008, 21:47 Uhr [ - Direktlink - ] |
Thema: Schwerwiegende Bugs im "Version"-Befehl:
Brett: Amiga, AmigaOS 4 Hallo, nachdem ich mich letztens über Holgers Reaktionen ärgern mußte, habe ich den heutigen Feiertag gleich mal genutzt, um meine eigenes Programm zu diesem Problemchen zu schreiben. Eine Sache, die ich eigtl. vermeiden wollte. Rückblickend betrachtet wäre es aber der schnellere Weg gewesen :-(( Nochmal kurz die Ausgangsposition: Eine Library stand/steht durch Benutzung in der entsprechenden Liste. Hier: xpkFAST.library V1.9 Weitere Files, die auf ".library" enden müssen, um den Bug zum Vorschein zu bringen, werden testweise aufgerufen. Hier: dieselbe Library in den Versionen 0.90 in Libs_alt/ und 1.10 in Libs_neu/ Alle oben aufgezählten "Version"-Versionen zeigen V1.9 für alle drei Dateien bzw. gar keine Version - ein klarer Bug. Und das bei allen möglichen Options-Kombinationen aus FILE und FULL. Eine mögliche Fehlbedienung, die mir hier vorgeworfen wurde, ist und war also nie gegeben. Hier nochmal kurz die Ausgabe von Version: code:--> Falsch !4.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library xpkFAST.library 1.9 code:--> Falsch !4.RamDisk:> version df0:Libs_neu/compressors/xpkFAST.library xpkFAST.library 1.9 code:--> (zufällig) richtig, da identisch mit der Version der geladenen Lib4.RamDisk:> version libs:compressors/xpkFAST.library xpkFAST.library 1.9 Und nun die Ausgabe von My-Version: code:--> Richtig !4.RamDisk:> My-Version df0:Libs_alt/compressors/xpkFAST.library xpkFAST.library V0.90 (28-Mar-1993) code:--> Richtig !5.RamDisk:> wb:c/My-Version df2:Libs_neu/compressors/xpkFAST.library xpkFAST 1.10 (20.09.1998) code:--> Richtig !5.RamDisk:> wb:c/My-Version libs:compressors/xpkFAST.library xpkFAST 1.9 (04.04.1998) Beim mittleren Beispiel habe ich beim Programmieren gemerkt, daß es zwei verschiedene Versionsstringarten gibt: Die "offizielle", die mit "$VER: " beginnt sowie die verbreitetere, bei der der Name der Library, abgeschlossen mit einem Nullbyte, dem eigtl. Versionstring vorangeht. Perfekt ist das Programm noch nicht (V0.1, ein Abend), aber für den Tests beliebiger Files allemal besser als das Original... Mein Befehl hat sogar den Vorteil, daß er die Datei - in Schritten von 11264 Bytes, also DD-Disk-Trackgröße - nur bis zum Versionsstring liest. Das Commodore-Prog dagegen liest das komplette File ein, selbst wenn der String ganz am Anfang steht - da kann man dann schonmal 'ne Minute sinnlos warten... Apropos unzulänglich: Beim Testen habe ich heute noch einen Bug entdeckt: Eigtl. wollte ich ja die version.library verwenden, doch weder in den RKRMs, dem Guru- oder dem Profi-Know-How-Buch, den Autodocs, den LVO/FD-Files oder den Includes waren Infos über die enthaltenen Funktionen zu bekommen. Also habe ich mein Prog halt selber geschrieben. Um zu testen, ob die Library überhaupt im Speicher steht, habe ich zuerst ein großes File auf Diskette untersuchen lassen, um während der Laufzeit von "Version" mit einem Monitor die Library-Liste anzusehen - nix. Und das, obwohl der Befehl jedesmal die version.library öffnet. Also habe ich versucht, den Befehl möglichst oft hintereinander zu starten, um während dieser Zeit die Liste durchzugehen: code:list libs:#? all lformat "version %s%s" >ram:test execute ram:test Das habe ich erstmal so durchlaufen lassen - alles OK. Und dann dasselbe mit SnoopDOS (noch ohne Monitor) -> Crash ! Dieser Crash ist reproduzierbar und tritt 1-2 Sekunden nach dem Start des Scripts ein. Führt man die Zeilen einzeln (bei laufendem SnoopDOS) aus, passiert auch nichts. Erklären kann ich mir dies nicht, denn selbst wenn "Version" nicht reentrant wäre, startet doch der nächste Befehl erst, wenn der vorherige die Kontrolle abgegeben hat. Auch sind bei mir noch nie Abstürze durch das Starten von SnoopDOS aufgetreten. Natürlich ist bei mir jetzt erstmal das Prog verdächtig, welches bisher viele Bugs gezeigt hat... Aber vielleicht gibt es ja noch eine andere Erklärung ? Gruß uho @DieterG: Klingt plausibel, kann ich jetzt auf die Schnelle (online) nix dazu sagen ("SEARCHING FOR $" [alter Insiderwitz]) |
|||||
|
uho
Nutzer
17.11.2008, 12:55 Uhr [ - Direktlink - ] |
Thema: Schwerwiegende Bugs im "Version"-Befehl:
Brett: Amiga, AmigaOS 4 @Holger: Zitat: Stimmt. Diese Zeile habe ich online (also unter Zeitdruck) hinzugefügt und prompt vergessen, die FILE-Option zu entfernen. Die Ausgabe ("Objekt nicht gefunden") bleibt davon aber unberührt. Dies legt nahe, daß die xpk-Lib doch wieder aus dem Speicher entfernt wurde. Gleichzeitig belegt dies aber auch den von mir beschriebenen Bug, daß trotz expliziter Pfadangabe eine falsche Versionsnummer angezeigt wird - noch dazu von einer Library-Version, die es offiziell gar nicht mehr im System geben dürfte ! Zitat: Ja, DEINE Ausgabe. Es ging aber um die Bugs auf meinem Rechner - aber man muß die Beiträge halt KOMPLETT LESEN. Und nicht nur die Zeile, die evtl. in die eigene Argumentation paßt. Nicht umsonst habe ich die gängigsten Versionen von WB 1.3 - 3.1 getestet. Hier also nochmals die entscheidenden Ausgaben: (Beachte, daß es um zwei unterschiedliche Pfade [Libs_alt und Libs_neu] geht - kann man leicht übersehen) Zitat: Man kann sogar genau sagen, welche Option was bewirkt: FILE unterdrückt die (sonst vorhandene) Versionsausgabe und fügt stattdessen den absoluten Pfad hinzu. FULL bewirkt, daß zusätzlich das Erstellungsdatum angezeigt wird. Vor allem Ersteres ist sicher nicht im Sinne des Erfinders gewesen - halt ein weiterer Bug - zusätzlich zur falschen Versionsausgabe. (Denn wozu sollte ein "Version"-Aufruf gut sein, wenn gerade die Versionsnummer nicht angezeigt wird ?!) Apropos falsch: Deine Shell-Zitate beweisen, daß Du das Anliegen dieses Threads gar nicht verstanden hast, denn mit nur einem Pfad bzw. einer Library-Version kann man den ganz oben angesprochenen Bug halt nicht nachvollziehen... Zitat: Und wieder: Erst LESEN, dann kritisieren ! Erstens haben sich die meisten xpk-Libs stets als zuverlässig erwiesen. Hier bist DU es also, der lieber armen Libraries die Schuld in die Schuhe zu schieben versucht, anstatt sich mit meiner Argumentation zu befassen... Zweitens kann man den Versions-String im Hex-Editor ansehen, falls man derartige Zweifel hegt. Aber für Dich ist das ja "vollkommen überflüssig"... Drittens mögen die Libs zwar alt sein, sind aber durchs "Lagern" sicher nicht fehlerhafter geworden. Und viertens habe ich schon in meinem ersten (!) Beitrag erwähnt, daß ich auch andere Libs mit dem gleichen Ergebnis getestet habe. Die xpk-Libs habe ich einfach deshalb gewählt, da sie normalerweise beim Bootvorgang nicht benötigt werden, aber jederzeit temporär oder auch dauerhaft in die Liste der genutzten Libraries aufgenommen werden können. Dadurch werden die Beispiele für andere leichter nachvollziehbar. Zusammenfassend kann man sagen: Du hast Deine "Version"-Versionsnummer nicht verraten. Das wäre Grundlage für sinnvolle Vergleiche gewesen. Du hast keinen Hex-Editor benutzt, um unabhängig vom "Version"-Befehl festzustellen, mit welchen Libraries du wirklich arbeitest. Du hast meine Beispiele nicht nachvollzogen, da es Dir wohl zu aufwendig war, eine Library in zwei unterschiedlichen Versionen zu besorgen. Daher hast Du meinen Bericht nicht vollständig gelesen/verstanden. Dafür hast Du viel kritisiert und dabei nur einen kleinen Treffer gelandet, mich aber zu vielen unnötigen Wiederholungen genötigt. Und Du hast nichts (hilfreiches) zu dieser Diskussion beigetragen Zitat:Wenn Du meinst... Gruß uho |
|||||
|
uho
Nutzer
17.11.2008, 12:51 Uhr [ - Direktlink - ] |
Thema: Schwerwiegende Bugs im "Version"-Befehl:
Brett: Amiga, AmigaOS 4 @Lippi: Ja, kleiner Flüchtigkeitsfehler in dieser Zeile, da unter Zeitdruck geschrieben. Die Ausgabe bleibt aber dieselbe - siehe Antwort an Holger Gruß uho |
|||||
|
||||||
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|