|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
|
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, 22:10 Uhr [ - Direktlink - ] |
Thema: V: ein paar Amiga und Hardwareteile
Brett: Kleinanzeigen (keine Auktionen!) Hallo, also Du bist einer dieser Typen, der einem nur ein Bild (.JPG) zusendet und sich ein Spiel bezahlen laesst ? ;-) Hehe, war nur Spaß. Bei EBay soll sowas mal gaengig gewesen sein... 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, 14:45 Uhr [ - Direktlink - ] |
Thema: Amiga beim RTL-Nachtjournal
Brett: Get a Life (war schon vorgestern) Hallo, Anläßlich des 50jährigen Bestehens von Computerspielen wurden u.a. PacMan und das erste, auf einem Oszi realisierte, Computerspiel - Tennis for two - erwähnt. Leider nicht erwähnt, aber immerhin kurz im Bild, war auch ein Amiga 500 sowie diverse Spieleboxen, darunter Klassiker wie Dungeon Master und Turrican. Aber um das zu erkennen, brauchte man schon die Standbild- Funktion... Wie gesagt, ist nicht viel; aber wir Amiga-Fans mußten ja schon vor vielen Jahren froh sein, wenn unser Rechner mal irgendwo kurz erwähnt wurde... Gruß uho [ Dieser Beitrag wurde von uho am 17.11.2008 um 14:46 Uhr geändert. ] |
|||||
|
uho
Nutzer
17.11.2008, 13:03 Uhr [ - Direktlink - ] |
Thema: V: A4000-D wird aufgelöst, viele Teile...
Brett: Kleinanzeigen (keine Auktionen!) @_PAB_: Hallo, hätte evtl. Interesse am HD-LW und dem 2MB-Chip-RAM-Riegel. Wie sind da die Preise ? Gruß uho |
|||||
|
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 |
|||||
|
uho
Nutzer
13.11.2008, 18:55 Uhr [ - Direktlink - ] |
Thema: V: Verschenke...
Brett: Kleinanzeigen (keine Auktionen!) Hallo, mich würden die Imagine-Kino-Tricks interessieren... Gruß uho |
|||||
|
uho
Nutzer
13.11.2008, 18:50 Uhr [ - Direktlink - ] |
Thema: Schwerwiegende Bugs im "Version"-Befehl:
Brett: Amiga, AmigaOS 4 Zitat: Muß ich jetzt das Wort "beziehungsweise" erläutern ?! Schließlich habe ich nicht umsonst stets den expliziten Pfad angegeben, da es in diesem Bug-Report ausschließlich um Dateien gehen soll. Zitat: Ja, mit einer Version. S.u. ... Unsere Version-Befehle haben wohl unterschiedliche Versionen Jedenfalls verhalten sie sich unterschiedlich, womit dann dieser Nebendisput zu erklären ist. Hier die Resultate, die ich erhalte: code:10.RamDisk:> version xpkFAST.library Objekt nicht gefunden 10.RamDisk:> version xpkFAST.library full Objekt nicht gefunden 10.RamDisk:> version xpkFAST.library file full Objekt nicht gefunden 10.RamDisk:> version xpkFAST.library file Objekt nicht gefunden (logisch, wenn nicht im Speicher) code:10.RamDisk:> version sys:Libs/compressors/xpkFAST.library xpkFAST.library 1.9 10.RamDisk:> version sys:Libs/compressors/xpkFAST.library full xpkFAST.library 1.9 (29.10.92) 10.RamDisk:> version sys:Libs/compressors/xpkFAST.library file Online:Libs/compressors/xpkFAST.library 10.RamDisk:> version sys:Libs/compressors/xpkFAST.library file full Online:Libs/compressors/xpkFAST.library (29.10.92) 10.RamDisk:> version sys:Libs/compressors/xpkSHRI.library file full Online:Libs/compressors/xpkSHRI.library 10.RamDisk:> version sys:c/Version version 39.4 Wie erläutert, unterdrückt die Option FILE die Versionsausgabe sogar ! Sinn macht lediglich die FULL-Option. Zum nachvollziehen des Bugs ist sie aber weder notwendig noch hilfreich... Der springende Punkt war halt die Falschausgabe der Versionsnummer. Und die läßt sich auch mit obigen Parameterkombinationen nicht unterbinden. Jetzt also nochmal - und damit den Thread unnötig verlängernd - der Test in aller Ausführlichkeit mit Files von Diskette: code:10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library xpkFAST.library V0.90 (28-Mar-1993) 10.RamDisk:> version df0:Libs_neu/compressors/xpkFAST.library xpkFAST.library 1.10 Diese Versionen sind korrekt ! Nun z.B. Backup-Prog starten und wieder beenden. Und nun gibt's folgende - völlig falsche - Versionsnummern TROTZ expliziter Pfadangabe: code:10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library xpkFAST.library 1.9 10.RamDisk:> version df0:Libs_neu/compressors/xpkFAST.library xpkFAST.library 1.9 10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library file Leer:Libs_alt/compressors/xpkFAST.library 10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library full xpkFAST.library 1.9 (29.10.92) 10.RamDisk:> version df0:Libs_alt/compressors/xpkFAST.library file full Leer:Libs_alt/compressors/xpkFAST.library Es wird ab jetzt und bis zum nächsten Reset (!) einfach die im Speicher stehende Version widergegeben. DAS ist der Bug, um den es hier geht. V1.9 sollte nur ausgegeben werden, wenn ich die Library OHNE Pfad angebe ! Und selbst jetzt - wo ja aufgrund der Version-Ausgabe zu vermuten wäre, daß V1.9 (fälschlicherweise, da UseCnt 0) irgendwo im Speicher 'rumhängt, lautet die Ausgabe ohne Pfadangabe wie folgt: code:10.RamDisk:> version xpkFAST.library file full Objekt nicht gefunden Hier, wo ausnahmsweise nicht die Datei gemeint ist, wäre V1.9 zu erwarten... Also, anstatt hier ständig 'rumzumäkeln wäre es sinnvoller, meine Tests mal wirklich mit (im Hex-Editor überprüften) UNTERSCHIEDLICHEN Library-Versionen nachzuvollziehen. (Ich weiß, manchmal sind meine Beiträge bischen lang - aber einzig, um möglichst komplett zu sein und so Mißverständnisse und Mehrfacherläuterungen zu vermeiden. Denn die sind im Endeffekt viel länger und schwieriger zu lesen. War leider wiedermal umsonst). Vielleicht tritt der Bug ja bei Euch wirklich nicht auf. Ist aber eher unwahrscheinlich... Schließlich veröffentliche ich ja meine mühsam erlangten Erkenntnisse nicht zum Spaß, sondern um andere Amiga-User vor Schaden zu bewahren bzw. einfach um Erkenntnisse zu teilen, damit das Rad nicht mehrfach erfunden werden muß. Eine (hilfreiche) Resonanz würde mich zwar freuen, ist aber leider viel zu oft unerfüllte Hoffnung... Man könnte z.B. versuchen, einen Patch zu entwickeln bzw. eine bugfreie Version zu entwickeln (ersteres wäre auch für den ebenfalls von mir entdeckten XCopy-Bug wünschenswert). Das wäre ein überschaubares (ok, man könnte auch weniger schönes Wort benutzen, hehe ;-) ) Projekt, in das sich mehrere Leute einbringen könnten... Gruß uho |
|||||
|
uho
Nutzer
12.11.2008, 15:51 Uhr [ - Direktlink - ] |
Thema: Schwerwiegende Bugs im "Version"-Befehl:
Brett: Amiga, AmigaOS 4 @Holger, NoImag: Klar, Handbuch lesen ist kein Fehler. Und ich gestehe, daß ich dies zumindest in den letzten Jahren kaum noch gemacht habe. Aber in diesem Fall liegt ihr dennoch falsch, denn a) heißt es im Handbuch für die Ausgabe OHNE FILE-Parameter: "Wenn ein Name angegeben wird, wird die Bibliothek, der Geräte- treiber, das Laufwerk bzw. die Datei geöffnet..." Mein Test war also korrekt. b) Die Option FILE ist in der Tat naheliegend. Doch bevor man mit RTFMs schleudert, sollte man die Sache erstmal ausprobieren ! Es wird dann nämlich keine Version mehr angegeben, sondern lediglich das Erstellungsdatum (xpkFAST) bzw. gar nichts mehr (xpkSHRI) - abgesehen vom - ohnehin bekannten absolute Pfad. Daran ändert auch die FULL-Option nichts. Auch mit "richtigen" Libraries wie der req.library wird keine Version mehr ausgegeben und die Sache wird sinnlos... Gruß uho |
|||||
|
uho
Nutzer
11.11.2008, 19:46 Uhr [ - Direktlink - ] |
Thema: Schwerwiegende Bugs im "Version"-Befehl:
Brett: Amiga, AmigaOS 4 Schwerwiegende Bugs im "Version"-Befehl: Den Version-Befehl kann man sehr vorteilhaft verwenden, um z.B. in unübersichtlich gewordenen Datenbeständen oder zwischen verschiedenen Computern Daten abzugleichen bzw. Doppelgänger zu löschen. Dummerweise gibt's da einen bösen Bug, der einen dazu verleiten kann noch benötigte Libraries zu löschen: Denn es wird eine falsche Versionsnummer angezeigt, wenn eine Library schon im Speicher steht, man aber die Version auf einem File z.B. auf Diskette wissen will. Dieser Effekt tritt sogar auf, wenn man den Pfad explizit angibt und auf diesem Verzeichnis auch kein Path- bzw. Assign-Eintrag liegt. Beispiel: version df0:libs/compressors/xpkFAST.library > V1.10 (richtig) version libs:compressors/xpkFAST.library > V0.90 (auf HD; ebenfalls korrekt) Jetzt die Library laden (z.B. entspr. Backup-Prog starten und wieder beenden (Libs sollten eigtl. wieder entfernt werden, das Use-Count 0 - und selbst wenn nicht - ich frage ja ein bestimmtes File und nicht das RAM ab.) Jetzt nochmal: version df0:libs/compressors/xpkFAST.library > V0.90 (FALSCH !!) Diese Fehlinformation bleibt bis zum nächsten Reset bestehen (nein, ein Avail FLUSH hilft nicht...) und kann insbesondere dazu führen, daß man versehentlich neuere Library-Versionen löscht, weil man sie für ältere bzw. Doppelgänger hält... Nach einigen Tests konnte ich den Bug wie folgt eingrenzen: - Tritt nur auf,wenn ein File auf ".library" endet. Benennt man das File auf der Disk um ("y" entfernen reicht) und paßt den Version-Aufruf entspr. an, wird die korrekte Versionsnummer ausgegeben ! Beispiel: rename df0:libs/compressors/xpkFAST.library... ...df0:libs/compressors/xpkFAST.librar (ohne 'y') version df0:libs/compressors/xpkFAST.librar > V1.10 (Richtig !!) Selbst wenn man dieses File an eine komplett andere Stelle kopiert, wird die Version trotz expliziter Pfadangabe nur solange korrekt angezeigt, bis man die Endung wieder in ".library" ändert. - Der Bug tritt (mindestens) bei den Versionen KS_1.3, 37.4 und 39.4 auf. (Version_KS1.3 [enthält keinen Versionsstring] weigert sich im Übrigen komplett, Dateien die nicht auf ".library" enden, zu öffnen ("Error in Open"). Und - um es ganz verrückt zu machen - führt man den vorherigen Aufruf (.library) auf das jetzt nicht mehr existierende File aus, wird es (angeblich) geöffnet und die (falsche!) Versionsnummer von vorhin ausgegeben). V37.4 macht's auch nicht besser und meint, daß da gar kein Versionstring wäre. Nach dem Umbenennen klappt's dann aber wieder. Aber das nur nebenbei...) Weitere Versionen zu testen überlasse ich der werten Leserschaft als Übungsaufgabe ;-) Gruß uho |
|||||
|
uho
Nutzer
11.11.2008, 19:42 Uhr [ - Direktlink - ] |
Thema: Diskettenphänomene
Brett: Amiga, AmigaOS 4 Diskettenphänomene - Nachtrag (uho, der Alleinunterhalter :-/ ) a) Validierungsprozeß manuell anstoßen: Mittlerweile habe ich mir das vollständige FFSTest-Archiv herunter- geladen und entdeckt, daß dort ist ein Prog namens "validate" dabei ist... b) XCopy-Fehler Da ich vor einigen Tagen ein neu erstandenes Disk-LW auf Herz und Nieren getestet habe, ist mir durch Zufall folgendes aufgefallen: Der oben beschriebene Effekt, daß der Blockinhalt nach einer XCopy- Formatierung unverändert ist (aber dennoch physische Fehler erkannt werden, was ein "Vortäuschen" des Formatierens ausschließt), tritt _nicht_ auf, wenn mehr als eine Diskette auf einmal und _ohne_ Verify formatiert wird. Schaltet man das Verify ein, ist der Vorgang auch bei mehreren Disks wieder fehlerhaft. Diese Effekt ist (wiederum) unabhängig von den verwendeten Laufwerken. Will man also die Blöcke einer Diskette wirklich mit Nullen füllen (z.B. um Daten wirklich zu vernichten oder bei Experimenten mit Disk-Editoren veränderte Blöcke leichter aufzuspüren), bleiben nur folgende Möglichkeiten: 1) Formatieren mit XCopy (classic) zusammen mit einer weiteren Disk und ohne Verify. 2) Vor dem Formatieren erst mit XCopy "Löschen" durchführen; dann geht auch normales Formatieren mit nur einer Disk und (zweckmäßigerweise) Verify. In jedem Fall Extra-Zeit bzw. -aufwand... 3) XCopy-TNG verwenden (ist aber langsamer, umständlicher & häßlich). Wem es nur um das Vernichten der Daten geht, kann auch AmigaOS nehmen - aber mit den beschriebenen seltsamen Blockinhalten und entsprechend langsamer (die NOVERIFY-Option wurde schon lange entfernt, leider...) Soweit dazu. Und wenn Ihr von Bugs noch nicht genug habt: Im "version"- Befehl habe ich einen ebenfalls heimtückischen Fehler entdeckt - entspr. Text stelle ich heute ein... Gruß uho |
|||||
|
uho
Nutzer
13.10.2008, 20:04 Uhr [ - Direktlink - ] |
Thema: Mehrere Fenster öffnen
Brett: Programmierung @Der_Wanderer, thomas, Holger, ... bin zwar nicht mehr sehr aktiv hier, lese aber des öfteren. Und deshalb möchte ich mal ein dickes "Danke" aussprechen - für die unzähligen fundierten Beiträge, die oft schon die spannende Antwort enthielten, bevor ich mir die entsprechende Frage gestellt hatte. Danke ! Gruß uho |
|||||
|
uho
Nutzer
13.10.2008, 19:16 Uhr [ - Direktlink - ] |
Thema: Diskettenphänomene
Brett: Amiga, AmigaOS 4 @dandy, rbn: Hallo, ist zwar schön, daß Ihr Euch durch meine umfangreiche Beschreibung gekämpft habt. Allerdings sollte dabei klar geworden sein, daß diese aufwendig zusammen- gestellten Beobachtungen unter keinen Umständen auf Zufällen bzw. verunreinigten Köpfen beruhen können. Da träten komplett andere und leicht zu erkennende Symptome auf. Außerdem werden meine LWs eine jährlich vorbeugend gereinigt und auch sonst pfleglich behandelt... Aber irgendwie bin ich auch selbst schuld: :-( Um wenig hilfreiche bzw. mir schon bekannte Antworten zu vermeiden, versuche ich halt die Tests immer so "wasserdicht" wie möglich zu machen - mit dem Ergebnis, daß die zwangsläufig etwas längeren Fragen nur teilweise gelesen werden bzw. die Antworten mangels Wissen gleich ganz ausbleiben (s.a. das immer noch ungelöste Problem mit der vergeßlichen Echzeituhr in meinem A4000D...). Ein Disk-LW würde ich aber evtl. noch nehmen, da diesen Winter noch einige hundert Disks zur Analyse/Formatierung anstehen, hehe :-)). Am besten mit Track-Anzeige... Gruß uho |
|||||
|
uho
Nutzer
09.10.2008, 19:18 Uhr [ - Direktlink - ] |
Thema: Diskettenphänomene
Brett: Amiga, AmigaOS 4 Hallo, (ja, ich weiß, das Disks Retro sind. Aber deshalb sind wir ja hier, oder ?!) zuerst sollte ich erwähnen, daß die erwähnten "Probleme" auf ver- schiedenster Hardware und (natürlich) mit verschiedenen Disketten nachvollzogen werden konnte. Bei einer gestern (inzwischen: vor Monaten) durchgeführten aufwendigen Disk-Rettungsaktion sind mir eine Reihe seltsamer Dinge passiert: 1) XCOPY-Pro-Fehler ------------------- (kein Versionsstring, 77052 Bytes, von Originaldisk !) Gelegentlich nutze ich FFSTest (0.11). Obwohl manche Fehler übersehen werden, meldet es bei mit XCOPY formatierten Disks stets folgenden Fehler: ... Checking 1 bitmap blocks 1730..1761: C0000000 key 881: allocation error ... allocated: 2 keys (in 1 extents) ... In der FFS-Doku kann man dazu folgendes nachlesen: "key xxx: allocation error" - bitmap block xxx doesn't match with computed disk allocations" Dieses Problem tritt unter OFS und FFS auf, jedoch nicht, wenn die Disk mit dem OS formatiert oder nachträglich mit ReOrg oder DiskSalv (Validate) behandelt wird. Es bleibt jedoch bestehen, wenn Files auf die Disk geschrieben werden (was ja auch mit einer Neuerstellung der Bitmap einhergeht). Ob ein (erzwungener) OS-Validierungsprozeß das Problem behebt, konnte ich nicht nachvollziehen, da ein Reset während des Schreibens stets zu unlesbaren Disks führte. Kann man diesen Prozeß auf saubere Art von Hand anschieben ? Da auf einer leeren Disk nur die Boot-Blöcke belegt sind, kann eine falsche Bitmap eigtl. nur leere Blöcke als belegt kennzeichnen (nicht umgekehrt). Dennoch sind die Angaben zu freien/belegten Blöcken bei OS und XCopy identisch (OFS: 836/0K. FFS: 878/1K). Wenn schon falsche Bitmap, dann müßte da doch ein Unterschied sein, oder ? Bei XCopy-TNG tritt dieser Effekt nicht auf. Auch hatte ich in den ganzen Jahren noch nie ein Problem mit ungültigen/ defekten Disks, welche auf XCopy zurückzuführen wären. Dennoch wäre es interessant, ob es Abhilfe (Patch) gibt bzw. wie "ernst" die Sache ist. Nachtrag: Der o.g. Fehler läßt sich mit DisKey 2.1 reparieren, indem im Block 881 (Bitmap) das LW 55 von 0x3fffffff auf 0xffffff gesetzt und die Prüfsumme (LW 0) von 0xc000c037 auf 0x0000c037 korrigiert wird. Außerdem ist mir dabei aufgefallen, daß selbst die Fehlermeldung von FFSTest fehlerhaft ist - sie zeigt immer nur das obere Wort dieses LWs an... Seltsam ist auch der angemeckerte Bereich: 1730..1761 wären 32 Blöcke. Das ist erstens kein ganzzahliges Vielfaches eines Tracks und zweitens sind das viel mehr Blöcke, als ich Bits geändert habe (0x3f -> 0xff = 2 Bits). Da sollte eher 1730+1731 stehen... Auch wenn die LW-Grenzen als Bereich sehen will, wäre stattdessen 1728..1759 logisch - und würde sich (oh Wunder) auch mit der Disk-Größe decken. Aber bei V0.11 sollte ich vielleicht nicht so kritisch sein :-) . 2) Seltsame Daten auf formatierten Disks ---------------------------------------- Bei dieser Gelegenheit ist mir aufgefallen, daß die Datenblöcke formatierter Disketten nicht leer sind. Mal abgesehen von Boot- und Root-Block schreibt XCopy irgendwelche (?) Daten hinein. (Einschub: mittlerweile ist klar, daß es Daten von gespeicherten Files sind (s.u.), die aber auch trotz mehrfachen kompletten Formatiervorgängen noch erhalten sind. Einige Blöcke werden aber "genullt". Formatiert man die betroffenen Blöcke z.B. mit DisKey, bleiben sie auch nach erneuter XCopy-Behandlung auf 0) Beispiel: code:Block 0: DOS1+ Nullen - OK Block 1: Nullen - OK Block 2: 0000: 72616E71 75652E22 0A29290A 0A287365 ranque.".))..(se 0010: 74202372 65626F6F 740A2863 61742022 t #reboot.(cat " 0020: 4C612069 6E737461 6C616369 F36E2064 La instalación d 0030: 6520576F 726B6265 6E636820 332E3120 e Workbench 3.1 0040: 68612074 65726D69 6E61646F 2E5C6E5C ha terminado.n 0050: 6E220A20 20202020 22506172 61206163 n". "Para ac ... 01D0: 20706F75 7220696E 7374616C 6C657220 pour installer 01E0: 6C652057 6F726B62 656E6368 20332E31 le Workbench 3.1 01F0: 220A2929 0A0A2873 65742023 696E7472 ".))..(set #intr Bei AmigaOS dagegen sieht es so aus: code:Block 1: 0000: 444F5381 444F5381 444F5383 444F5383 DOS.DOS.DOS.DOS. 0010: 444F5385 444F5385 444F5387 444F5387 DOS.DOS.DOS.DOS. ... 01D0: 444F53F5 444F53F5 444F53F7 444F53F7 DOSõDOSõDOS÷DOS÷ 01E0: 444F53F9 444F53F9 444F53FB 444F53FB DOSùDOSùDOSûDOSû 01F0: 444F53FD 444F53FD 444F53FF 444F53FF DOSýDOSýDOS.DOS. Block 1234: 0000: 444F5B81 444F5B81 444F5B83 444F5B83 DO[.DO[.DO[.DO[. 0010: 444F5B85 444F5B85 444F5B87 444F5B87 DO[.DO[.DO[.DO[. ... 01D0: 444F5BF5 444F5BF5 444F5BF7 444F5BF7 DO[õDO[õDO[÷DO[÷ 01E0: 444F5BF9 444F5BF9 444F5BFB 444F5BFB DO[ùDO[ùDO[ûDO[û 01F0: 444F5BFD 444F5BFD 444F5BFF 444F5BFF DO[ýDO[ýDO[.DO[. Der Inhalt ist nicht völlig zufällig, unterscheidet sich aber von Block zu Block. Das letzte Byte ist wohl eine lfd. Nr., die von der Block-Nr. beeinflußt wird - allerdings mit Sprüngen (01/81, 02/82, ...), wobei es einen Übertrag auf das 'S' von "DOS" zu geben scheint. Aber wozu das Ganze ? Warum keine Nullen ? 3) Hardware spinnt ------------------ (nicht mehr reproduzierbar) Wohl mit keiner Logik zu erklären ist das gestrige Versagen gleich mehrerer externer Disk-Laufwerke: Dabei wurden beim Schreiben auf eine leere Disk fast immer Fehler erzeugt - meist bei Block 881-883. Außerdem schrieb XCopy beim formatieren zufällige Daten (die Disks waren aber dennoch verwendbar, da die Blöcke ja als leer markiert waren). Insgesamt habe ich so ziemlich alle Kombinationen aus zwei 1200ern, zwei DD- und einem HD-LW sowie zwei Netzteilen (1200er + 500er) und natürlich diversen Disks getestet. Überall das Gleiche. Die Probleme traten aussschließlich bei den externen Laufwerken auf, nicht bei den internen ! Da ich ja auch mit dem (stärkeren) A500-Netzteil getestet habe, kann man eine zu schwache Stromversorgung wohl ausschließen... Besonders beunruhigt haben mich aber Abstürze, die nur beim Schreiben auftraten. Oft wurden kurz vorher Pixel quer über den Bildschirm geschrieben - wohl ein Problem im Zusammen- hang mit dem Blitter, der ja die Disk-Daten (De)kodiert. Hat jemand von euch schonmal etwas Ähnliches erlebt ? Gibt es da einen Designfehler ? Oder kündigt sich da ein Hardwaredefekt an ? Jedenfalls hatte ich in den ganzen Jahren nie derartige Probleme und nach ein paar Stunden war alles vorbei. Hab' ich vielleicht 'ne Sonneneruption verpaßt ?? Nachtrag: Der Text sollte eigtl. schon vor Monaten eingestellt werden - entspr. Sonnenwinde müßten also schon 'ne Weile her sein... Nach soviel Text zusammenfassend die Fragen: - Hat(te) jemand ähnliche Probleme/Beobachtungen ? - Gibt es einen Patch für XCopy ? - Ist bekannt, ob zwischen/in den Blöcken mit Datenresten durch XCopy sowas wie ein Wasserzeichen hinterlassen wird, um den Nutzer zu ermitteln ? Ursprünglich war XCopy ja nur direkt bei Cachet erhältlich und bei Druckern/Kopieren ist das Ausgeben versteckter Pixel, die Seriennr., Uhrzeit etc. preisgeben ja leider seit Jahren gang und gäbe... Für den unbedarften User scheint die Disk ja eh leer, doch schon ein oberflächlicher Blick mit einem Disk-Editor würde evtl. Botschaften entlarven. Im Datenmüll wären sie kaum zu ermitteln, da man die Originaldaten ja i.A. nicht kennt... - Wie würde man OS-konform das entspr. LW in Block 881 korrigieren (die Anleitung für die Checksumme hab' ich IMHO noch irgendwo) ? - Kennt jemand die Gründe und/oder den Algorithmus, mit dem die Blöcke bei AmigaDOS gefüllt werden ? Warum keine Nullen ? - Kann jemand bestätigen, daß der durch XCopy erzeugte Bitmap-Fehler - entspr. meinen jahrelangen Erfahrungen - tatsächlich harmlos ist ? Einzig in ganz, ganz seltenen Fällen ist mir ReOrg mit Datenverlust abgeschmiert. Das kann aber auch andere Ursachen gehabt haben und ein heutiger Test mit einer ziemlich vollen derartigen Disk ergab keinerlei Probleme. - Wie stößt man - idealerweise ohne ein Prog schreiben zu müssen - einen Validierungsprozeß bei einer intakten Disk an ? Gruß uho |
|||||
|
uho
Nutzer
12.08.2008, 20:22 Uhr [ - Direktlink - ] |
Thema: S: Progger-Sonderhefte
Brett: Kleinanzeigen (keine Auktionen!) Hallo zusammen, ich suche alle Amiga-Magazin-Sonderhefte "Faszination Programmieren" - abgesehen von Nr.2. Wieviele es gab, weiß ich nicht, mind. jedoch drei. War ab ca. 1992. Schonmal danke für ein evtl. Angebot. Gruß uho |
|||||
|
uho
Nutzer
21.05.2008, 09:53 Uhr [ - Direktlink - ] |
Thema: S: Indiana Jones und der letzte Kreuzzug
Brett: Kleinanzeigen (keine Auktionen!) ...in deutsch und mit vollständiger Verpackung. Wen kann ich überreden sich von diesem Spiel zu trennen ? Gruß uho |
|||||
|
uho
Nutzer
22.04.2008, 11:55 Uhr [ - Direktlink - ] |
Thema: S: Techniker...
Brett: Kleinanzeigen (keine Auktionen!) @syntax: komm' doch dieses WE zum VCFe (www.vcfe.org) und bring den Akku mit. Ich habe sowieso den Lötkolben dabei... Gruß uho |
|||||
|
uho
Nutzer
23.03.2008, 11:54 Uhr [ - Direktlink - ] |
Thema: Suche einige Amigatitel :)
Brett: Amiga, AmigaOS 4 @R-TEAM: Tja, was soll man zu so einem "Beitrag" groß sagen ? Deine "Annahmen" sind durchweg falsch - egal ob es um Farbtiefe, verwendete Plattform oder meine Amiga-'Historie' geht. Und den Artikel über die CF-Karten hast _Du_ nicht richtig gelesen, nicht ich... Es ist ja nichts dagegen einzuwenden, wenn man seinen Träumen nachhängt. Aber wenn Du aus der Luft gegriffene Behauptungen als Tatsachen hinstellst bzw. diese selbstgeschaffene So-würde-es-mir-gerade-in-den-Kram-passen-Welt nicht mehr von der Realität unterscheiden kannst, solltest Du Dir vielleicht fachkundige Hilfe suchen. Im Übrigen weiß ich gar nicht, weshalb Du die OS-Kritik so persönlich nimmst - programmiert hast Du es mit Sicherheit nicht (obwohl, wenn ich ich die Schöpfungs"höhen" vergleiche...). Für mich ist die "Diskussion" mit Dir damit jedenfalls beendet - Zeit ist ein zu wertvolles Gut. uho |
|||||
|
uho
Nutzer
23.03.2008, 11:52 Uhr [ - Direktlink - ] |
Thema: Hilfe ! Uhr legt A4000D komplett lahm !
Brett: Amiga, AmigaOS 4 Hallo, habe wieder einige Tests mit der defekten Uhr im A4000D gemacht. Dabei ist mir folgendes aufgefallen: Der Kondensatoren im 5V-Kreis sind doch OK. Der "Kurzschluß" befindet sich auf dem Zorro(Daughter)-Board. Sobald ich es rausziehe, piept der Durchgangsprüfer auf dem Mainboard (z.B. bei C 192) nicht mehr. Seltsamerweise gibt es diese Verbindung zwischen den Pegeln aber auch auf meinem - noch funktionierenden - Rechner aber auch ! Wer kann das erklären ? Wieso sollten die Pegel regulär verbunden sein ? Das ist doch unsinnig, oder ? Hatte ich den Rechner komplett zerlegt. Jetzt scheint (!) er (ohne Zorro-Slots) zu laufen. Der gelbe Bildschirm ist weg. Die Uhr geht aber immer noch nicht. D.h. "Setclock load" liefert immer den 1.1.78, egal, was man vorher reinschreibt. Die Uhr selber scheint aber zu laufen. Der Quarz geht jedenfalls, und am ALARM-Ausgang kommen 1Hz/16Hz-Pulse an (zur Feineinstellung). Durch Messung mit dem Oszi habe ich beobachtet, daß sich zwar die RD-Leitung (Pin  "normal verhält (geht nur bei "setclock load"mehrmals kurz auf Masse), auf der WR-Leitung (Pin 10) aber das absolute Chaos herrscht: Ein Puls jagt den nächsten, sämtlich total verzerrt (ähnlich abgerundeter Sägezähne), großteils außer- halb der für die Uhr vorgeschriebenen Mindestbreite und oft nicht den vollen Pegel erreichend. OK, dachte ich: Fehler gefunden. Liegt am Compi. Nix zu machen. Mist. Eine Vergleichsmessung brachte aber wiederum ein ähnliches Ergebnis bei meinem Rechner mit intakter Uhr ! Außerdem ist mir völlig unklar, wieso ständig in die Uhr _geschrieben_ werden sollte - noch dazu hunderte Male in der Sekunde. Lesen wäre da noch logischer - und schon das passiert nur auf Anweisung. Mir gehen langsam wirklich die Ideen aus. Vielleicht habt ihr ja noch eine ? Ebenfalls interessant wäre eine Bezugsquelle (Name: Ricoh RP5C01) und evtl. der Name (idealerweise mit Mail-Adresse) des für diesen Bereich zuständigen Amiga-Entwicklers. Letzteres wohl besser heute als morgen, bevor der auch noch aus dem Fenster springt :-/ Gruß uho |
|||||
|
uho
Nutzer
19.03.2008, 21:42 Uhr [ - Direktlink - ] |
Thema: Suche einige Amigatitel :)
Brett: Amiga, AmigaOS 4 @bluebird: Ja, so war das gemeint. Womit ich aber damit weder die Unzuläng- lichkeit "aktueller" Amiga-Browser noch die wie Pilze aus dem Boden sprießenden Web-"Services" verteidigen will. Es sollte nur ein augenzwinkerndes "Hey, nutzt doch 'richtige' Amigas" sein. @t2skynet: Sei doch nicht so humorlos. Soo bierernst war dieser Einwurf nun auch wieder nicht... @r-team: AmigaOS-Versionen >3.1 verdienen ihren Namen nicht. Hatte mal 3.5 installiert - war selbst aufm 060er unbenutzbar langsam... Und auf einem aktuellen CF-Thread wird gerade geschwärmt, daß man die OS4-Installation (wahrscheinlich sogar von CD) durch den schnellen Zugriff von einer Stunde (!!!) auf 30 Minuten drücken kann. Na danke, da kann man sich auch gleich mit Windows rumärgern ! Wir wir ja alle wissen, war das AmigaOS vorher selbst auf eine normale Festplatte (<1MB/s auf A500 z.B.) von den zig-fach lang- sameren Disketten in ca. 5-10min installiert. Wenn man die höhere Transferrate & Rechenleistung mit der zusätzlich benötigten Zeit multipliziert, muß man sich schon fragen, wie ein hocheffizientes System innerhalb nur weniger Versionssprünge derart kaputtprogrammiert werden konnte. Daß es dank schnellem PPC & GraKa auf manchen Plattformen trotzdem noch benutzbar sein kann ist da beileibe keine Entschuldigung für die Programmierer... Gruß uho |
|||||
|
||||||
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|