amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 -3- 4 5 6 7 8 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)
gni   Nutzer

24.05.2007, 12:43 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Solar:
Zitat:
Reth:
code:
.../libstdc++.a(basic_file.o): undefined reference to 'getc'
.../libstdc++.a(basic_file.o): undefined reference to 'fdopen'


Die C++-Standardbibliothek versucht hier, C-Standard-Dateifunktionen einzubinden, die dann nicht gefunden werden... auch hier vermute ich einen fehlerhaften Linker-Aufruf.
In dem Fall wohl nicht. libnix fehlen einige stdio-Funktionen, u.a. auch getc(). Diese Funktionen sind als Makro in stdio.h vorhanden, müssen aber auch als echte Funktionen existieren. Bei fdopen liegt der Fall etwas anders. Es kann sein, das die von reth verwendete Version kein fdopen() hat. Da kann man nicht viel machen. Die fehlenden stdio-Funktionen können "nachgerüstet" werden, siehe dazu hier. Für fdopen() braucht es wohl eine neue(re) libnix Version, denke ich mal.
 
gni   Nutzer

22.05.2007, 16:28 Uhr

[ - Direktlink - ]
Thema: MorphOS PowerUp startet nicht auf A4k (schwarzer Bildschirm)
Brett: MorphOS

Zitat:
aPEX:
MOS auf Classic scheint ja nicht gerade beliebt zu sein. :)

Vermutlich will niemand mehrfach schreiben?
Zitat:
Niemand der noch eine Idee hat?
SFS, FFS, Algor, 68060.library, s-s, etc.
 
gni   Nutzer

16.05.2007, 08:17 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Bei:
C++ code:
#include <slist>

Bekomme ich aber gesagt:
code:
slist: No such file or directory


Versuchs mal mit <slist.h> oder dann mit <ext/slist>. Wenn Du Deinen Code mit beiden Compilerversionen übersetzen willst, kommst Du vermutlich um Fallunterscheidungen mittels "__GNUG__ > 2" wohl nicht rum.
Zitat:
Zitat:
Holger:
Bzw., wie es für C++ empfohlen wird, #include <cstring>

Hm bei mir hat hier wohl ein:
C++ code:
#include <string>

gelangt!?
Die Frage hätte Dir -H beantwortet. Kurz gesagt, das ist vermutlich ein Seiteneffekt, da <string> zum Einbinden von <cstring> führt. Ob das immer so sein muß, weis ich nicht. Wenn Du nur die die Prototypen für die C-Stringfunktionen benötigst, dann solltest Du wie Holger treffend anmerkte <cstring> einbinden.
 
gni   Nutzer

16.05.2007, 08:00 Uhr

[ - Direktlink - ]
Thema: Examine
Brett: Programmierung

Zitat:
MaikG:
Mit Seek bekommst du auch die größe ohne die Datei in den Speicher zu laden.

Schlechter Rat. Abhängig vom Dateisystem ist Seek() um ein Vielfaches langsamer als Examine().
 
gni   Nutzer

15.05.2007, 15:13 Uhr

[ - Direktlink - ]
Thema: Examine
Brett: Programmierung

Zitat:
Kaesebroetchen:
Aus AllocDosObject werde ich nicht so recht schlau. Die Dokumentation ist da recht spärlich: [...]

Da steht doch alles drin, was Du wissen mußt? Welche Werte "type" annehmen kann, ist in dos/dos.h dokumentiert (zb. DOS_FIB). Die Tagliste kann leer bleiben, entweder per NULL Argument oder eine leere Tagliste, die nur TAG_END enthält.
 
gni   Nutzer

15.05.2007, 14:37 Uhr

[ - Direktlink - ]
Thema: Examine
Brett: Programmierung

Zitat:
Kaesebroetchen:
Mache ich da irgenwas grundsätzliches falsch ?

Versuchs mal so:

struct FileInfoBlock MurksFib;
...
Examine( BPTRFileLock, &MurksFib );
return MurksFib.fib_Size;

und selbst das hat noch Potential für Nichtfunktionieren, da der FileInfoBlock langwortausgerichtet sein muß, dh. man braucht noch eine __aligned Direktive, die jedoch Compilerabhängig ist. Wenn Du das alles umgehen möchtest, dann allokierst Du den FileInfoBlock per AllocDosObject(), den Du dann natürlich per FreeDosObject() wieder freigeben mußt.
 
gni   Nutzer

15.05.2007, 09:52 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Unter 2.95.3 konnte ich mühelos die strlen-Funktion aus C auf ein char* anwenden (ohne was zu includieren). Der 3.3 kennt das nicht.

Sei froh das 3.3 das Benutzen von Funktionen ohne Prototype anmeckert. Du mußt _immer_ den entsprechenden Header für eine Funktion einbinden.
Zitat:
Muss ich hier irgend nen Standard-C-Header inkludieren, oder kann ich die Funktion gar nicht mehr verwenden und muss das Ganze über C++-Strings handhaben?
Dir fehlt nur "#include <string.h>".
Zitat:
In meinen Büchern und im Web hab ich nix gefunden (oder aber ich habs immer übersehen?), das besagt, dass die Default-Argumente nur bei der Deklaration angegeben werden dürfen, nicht aber bei der Definition
Defaultargumente sind nur in der Class-Definition zulässig. Neuere GCC Versionen halten sich in vielen Fällen strikter an Standards und finden mehr Probleme. Du solltest darüber nachdenken, auch bei GCC2 mit -W -Wall zu übersetzen. Auch da sollten dann etwaige Probleme bereits diagnostiziert werden.
Zitat:
Woran liegt das denn - will sagen, an welcher Klausel des Standards?
Wo das im Standard steht, kann ich Dir auch nicht sagen. Nimms einfach hin ;-)
 
gni   Nutzer

12.05.2007, 19:58 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Schaue bei Gelegenheit auch nochmal in alle installierten OS-Includes (3.x und 4), bzw. lass mir mal alles suchen, wo HOOKFUNC drin vorkommt und berichte dann (kann aber ne Weile dauern)!

Die Option -H zeigt Dir welche Includes benutzt werden.
 
gni   Nutzer

12.05.2007, 19:57 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Holger:
Sind Deine Testumgebungen auch, wie bei Reth, die von der GoldEd Installation oder andere?

Kein GoldED. Getestet habe ich mit Cross-Compilern, aber meine GCC Installtion unter AmigaOS ist prinzipiell die gleiche bezüglich Compiler und Includes.
 
gni   Nutzer

11.05.2007, 22:39 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
code:
ScreenModeHookC.cc:16: error: invalid conversion from 'long unsigned int (*)(...)' to 'ULONG (*)()'

Wieso wird der Fehler erst jetzt gemeldet und nicht schon bei den ersten 3.3er Compilierversuchen?
FWIW, kein Fehler mit allen von mir getesten GCC Versionen (2.95.x, 3.3.6, 3.4.6, 4.0.0, 4.1.0)
 
gni   Nutzer

11.05.2007, 14:13 Uhr

[ - Direktlink - ]
Thema: WBStartup Message
Brett: Programmierung

Zitat:
Holger:
Zitat:
gni:
Zitat:
darf man die WBStartup Message bis zum Programm Ende behalten und dann ReplyMsg'en ?
Man darf nicht nur, man _muß_.
Nur, wenn man noch darauf zugreifen will. Ansonsten kann man sie natürlich schon früher zurückschicken.
Die WB-Message darf definitiv erst am Programmende zurückgeschickt werden, da die WB nach dem ReplyMsg() den vom Programm belegten Speicher wieder freigibt (UnloadSeg). Deswegen muß das ReplyMsg() auch per Forbid() geschützt werden.
 
gni   Nutzer

11.05.2007, 12:31 Uhr

[ - Direktlink - ]
Thema: WBStartup Message
Brett: Programmierung

Zitat:
Der_Wanderer:
Das heisst, ich darf während das Program läuft auf die Message zugreifen, ohne vorher eine Kopie zu machen ?

Solange eine Nachricht in Deinem "Besitz" ist, kannst Du diese untersuchen. Kopieren einer Nachricht ist nicht möglich, wie sollte das auch gehen?
Zitat:
Der WBStartup Code von Amiblitz ist nicht von mir, und es sah so aus, also ob Amiblitz die Message abholt, Daten analysiert und dann sofort replied.
Da solltest Du wirklich nochmal schauen, weil so kann es nicht funktionieren.
Zitat:
Ich habe ja das RKM, NDK etc., aber ich kann dazu nichts finden. Unter welcher Lib o.ä. muss ich denn da gucken ?
WBStartup-Nachricht wird im Startupcode verarbeitet. Im NDK sollte irgendwo eine Quelle des C= Startupcodes sein (ist Assembler). Ansonsten gibt es viele Programme im AmiNet, die ohne Startupcode arbeiten und sich selbst um CLI/WB kümmern, zb. TolleUhr ;-)
 
gni   Nutzer

11.05.2007, 10:02 Uhr

[ - Direktlink - ]
Thema: WBStartup Message
Brett: Programmierung

Zitat:
Der_Wanderer:
Darf man Daten aus der WBStartup Message auslesen, wenn man sie schon ReplyMsg'ed hat ?

Nein. Wenn eine Nachricht bereits zurückgeschickt wurde, darf sie nicht mehr dereferenziert werden.
Zitat:
Wenn nein, darf man die WBStartup Message bis zum Programm Ende behalten und dann ReplyMsg'en ?
Man darf nicht nur, man _muß_.
Zitat:
Weiss jemand wo ich die Doku dazu finde ?
Guru-Buch? RKMs? NDK? Beispielcode?


[ Dieser Beitrag wurde von gni am 11.05.2007 um 10:03 Uhr geändert. ]
 
gni   Nutzer

11.05.2007, 08:53 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Zitat:
Holger:
Na ja, h_Entry und h_SubEntry sind ja auch vom Typ LONG und nicht HOOKFUNC.


HOOKFUNC ist ein Typedef eines Funktionszeigers.
Zitat:
Hm, vielleicht muss ich genauer casten. also:
C++ code:
this->filterHook.h_Entry = reinterpret_cast<ULONG (*)()>(HookEntry);
this->filterHook.h_SubEntry = reinterpret_cast<ULONG (*)()>(SMFilterFunc);


Und siehe dann, nun klappts!

Wenn man den richtigen Typ nimmt, kann man das auch erwarten. Der Compiler hat Dir ja gesagt, was er erwartet.
Zitat:
Wieso hat das ganze dann aber zuvor der g++ des 2.95.3 anstandslos compiliert und das Programm wurde auch immer normal ausgeführt!?
Weil 2.95.x nicht so genau hingeschaut hat? HOOKFUNC ist prinzipiell richtig. Allerdings gibt es unterschiedliche Defintionen von h_[Sub]Entry, mal mit und mal ohne Parameter.

Und noch was: <slist> gibt es sehr wohl auch bei GCC3!
 
gni   Nutzer

09.05.2007, 12:51 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Zitat:
Du kannst ja mal die Verzeichnisse mit diff vergleichen.
Meinst Du die des 2.95.3 mit denen des 3.3
Ja, so meine ich das.
 
gni   Nutzer

09.05.2007, 08:57 Uhr

[ - Direktlink - ]
Thema: Picasso96 aktuell
Brett: Amiga, AmigaOS 4

Zitat:
spock-79:
HIER gibts die
Version 2.1b.

Die emulation.library aus diesem Archiv konnte auf meinem System beim Booten nicht geladen werden, dh. mir fehlte die cybergraphics.library. Nachladen per Hand hat allerdings funktioniert. Ich würde empfehlen, bei 2.0 und dem nachgeschobenen rtg.library Update zu bleiben.
 
gni   Nutzer

09.05.2007, 08:50 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Hm, werds erstmal wegsichern oder umbenennen, nicht, dass der Compiler danach nicht mehr mag!

Wenn Du mit -v übersetzt, dann kannst Du sehen, in welchen Verzeichnissen Includes gesucht werden.
Zitat:
So sieht übrigens der jew. Include-Verzeichnisbaum aus: ...
Gibts da noch mehr falsch Abgelegtes?

Sieht nicht so aus. Du kannst ja mal die Verzeichnisse mit diff vergleichen.
 
gni   Nutzer

08.05.2007, 12:28 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Das liegt daran, dass diese Verzeichnisse in den jeweiligen include-Verzeichnissen liegen

Wenn im Include-Verzeichnis des 3.3 Baum wirklich ein g++-3 Verzeichnis zu finden ist, dann gehört das definitiv nicht dahin -> Löschen.

[ Dieser Beitrag wurde von gni am 08.05.2007 um 12:29 Uhr geändert. ]
 
gni   Nutzer

08.05.2007, 09:40 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
[Verzeichnis von 2.95.3 und 3.3]

Bei den Listings der Verzeichnisse ist nirgends g++-3 zu finden. Bist Du sicher, das das wirklich auch bei 3.3 vorhanden ist?
Zitat:
Ich frage mich allerdings, wieso im 3.3 im Vgl. zum 2.95.3 (meiner Meingun nach) sinnvolle Erweiterungen wie slist gecancelt wurden und sich anscheinend wohl "nur" auf den Standard konzentriert wurde.
Wenn Dich das wirklich interessiert, dann mußt Du auf der GCC Entwickler-ML nachfragen ;-)
Zitat:
Kann ich denn die slist mit den vorhandenen Includes innerhalb des 3.3 dennoch nutzen?
Das weis ich nicht, vermutlich aber eher nicht. Nimm "list" und gut.
 
gni   Nutzer

07.05.2007, 08:56 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Zitat:
Da Du sowohl 2.95.x als auch 3.x installiert hast, sind logischerweise beide Verzeichnisse vorhanden.
Nun nicht ganz, da beide Compiler bei GoldED einen komplett eigenen Verzeichnisbaum haben.
Was soll "eigener Verzeichnisbaum" bedeuten? Die C++ Includes liegen normalerweise in gg:include, dh. beide Compiler benutzen gg:includes für die Includesuche. Aber auch wenn die C++ Includeverzeichnisse in dem Verzeichnis sind, so sucht doch jeder Compiler nur in seinem eigenen C++ Verzeichnis.
Zitat:
In dem des 2.95.3 liegen u.a. die g++-3 und in dem des 3.3er die g++-3 und c++!
Bitte etwas ausführlicher.
 
gni   Nutzer

05.05.2007, 20:13 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Der GCC 3.3 findet die slist nicht, der 2.95.3 allerdings schon!

Vermutlich deswegen: The slist class, and the slist header, are an SGI extension; they are not part of the C++ standard.
Zitat:
Nun ist es so, dass die includes dazu beim 2.95.3 im Unterverzeichnis g++-3. Dieses gibt es auch beim 3.3er, dort ist aber auch noch das Unterverzeichnis c++, welches die anderen STL-Typen enthält (zumindest die, welche ich nehme), dafür keine slist!
Im Verzeichnis g++-3 sind die C++ Header für GCC 2.95.x, im Verzeichnis c++ sind die C++ Header von GCC3. Da Du sowohl 2.95.x als auch 3.x installiert hast, sind logischerweise beide Verzeichnisse vorhanden.
Zitat:
Wenn ich nun das g++-3 Verzeichnis beim GCC 3.3 bei den Compiler Options mit als Include angebe, dann bekomme ich massig deprecated Meldungden und Fehler angezeigt!
Das macht man auch nicht und kann man auch nicht machen! Jeder C++ Compiler hat seine _eigenen_ Header und auch _nur_ die kann man mit dem jeweiligen Compiler auch nur verwenden! Wo der Compiler seine Standard-Includes findet, weiss der Compiler selbst.
 
gni   Nutzer

04.05.2007, 17:05 Uhr

[ - Direktlink - ]
Thema: Exectuable Pfad und Icon
Brett: Programmierung

Zitat:
Der_Wanderer:
Gut, man könnte ein GetNameFromLock machen auf einen Lock auf ProgDir:.

Oops, richtig ich meinte PROGDIR: :-P
Zitat:
Es gibt doch aber auch functionen direkt in der dos.inlcude dafür, oder?
Hast Du kein NDK? Da stehen doch alle Funktionen drin ;) AFAIR, seit 2.0 gibt es GetProgramDir(), das Dir eventuell weiterhilft.
Zitat:
Also woher wiess ich, ob mein Prog aus der CLI, als WB Project oder als WB Program gestartet wurde ?
WB oder CLI unterscheidet man mittel pr_CLI aus der Prozeßstruktur. Wenn der Eintrag NULL ist, dann wurde der Prozeß von der WB gestartet und man muß die WB-Message einsammeln. Ist das nicht Amiga-Grundwissen? ;-)
 
gni   Nutzer

04.05.2007, 15:49 Uhr

[ - Direktlink - ]
Thema: Exectuable Pfad und Icon
Brett: Programmierung

Zitat:
Der_Wanderer:
a) den Pfad+Datei der eigenen Exectubale herauszufinden...

Reicht statt des richtigen Pfades auch HOMEDIR:? Eventuell kann man darüber auch den wirklichen Pfad ermitteln. Den Namen des Programmes rauszufinden, ist schon schwieriger. Bei Standard-C ist der in argv[0] zu finden (eventuell sogar mit Pfad) ;-) Ansonsten im Icon (WB) oder in der CLI-Struktur nachschauen. Dafür gibt es seit 2.0 auch spezielle Zugriffsfunktionen in der dos.libary (Get...).
Zitat:
b) das Icon herauszufinden über das man gestarted wurde, was ja nicht notwendigerweise exe+".info" sein muss, bei Projekt Icons kann es ja auch einen anderen Namen tragen.
Vorausgesetzt das Programm ist über die WB gestartet worden, kann man doch alles aus WBStartup rauskramen? An des Projekttool sollte man auch bei Projekticons rankommen.
 
gni   Nutzer

04.05.2007, 08:37 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Mit Namespaces war/bin ich noch nicht so firm, da das bisher beim 2.95.3 wohl kein Problem war!

Dan solltest Du dich damit vertraut machen. GCC2 hat einige Dinge laxer gehandhabt als die Nachfolgeversionen.
Zitat:
C++ code:
#include <string>
...
void setTitle(const string title = "") { displayTitle = title; }

Gab keine Probleme beim comilieren!
Wenn der obige Code mit GCC3 Probleme macht, dann liegt es definitiv am fehlenden Namespace. Entweder Du verpaßt jedem nacktem string den Prefix "std::" oder Du arbeitest mit "using namspace std;". Die Prefixvariante funktioniert im übrigen auch mit GCC2.95.x.
 
gni   Nutzer

03.05.2007, 12:19 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
thomas:
Zitat:
Parse error before ')' token
Das sieht für mich so aus, als wenn da schlicht die Header-Datei fehlt, in der string definiert ist.
Ich würde eher auf den Namespace tippen...
 
gni   Nutzer

03.05.2007, 12:17 Uhr

[ - Direktlink - ]
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
thomas:
Ich bin etwas verwundert über die Version 2.95.3. Soweit ich mich erinnere, war beim OS4-SDK immer die Version 3 von GCC dabei und das neueste SDK hat sogar Version 4.0.2

Die Frage bezieht sich nicht auf ppc-amigaos sondern auf m68k-amigaos.
 
gni   Nutzer

26.04.2007, 12:33 Uhr

[ - Direktlink - ]
Thema: NetBSD in 50 Hz PAL Modus booten?
Brett: Andere Systeme

Zitat:
lodger:
Ich habe eben in der Kernel-Config die option Parameter GRF_PAL und GRF_AGA aktiviert, alle andere GRF_ options habe ich auskommentiert.

Wenn Du AGA eh nicht benutzen kannst (und willst), kannst Du es auch weglassen. AFAIR braucht man auch GRF_NTSC.
Zitat:
Hast Du zufällig einen Link oder einen Newsgroupbeitrag parat, wo man die für den Amiga Port gültigen Kernelparameter nachlesen kann?
Die stehen alle in GENERIC drin, aber das hast Du ja bereits gefunden.
 
gni   Nutzer

25.04.2007, 16:06 Uhr

[ - Direktlink - ]
Thema: NetBSD in 50 Hz PAL Modus booten?
Brett: Andere Systeme

Zitat:
lodger:
Kennt hier jemand von den Insidern hier evtl. eine Möglichkeit, NetBSD in einem 50 Hz PAL Modus, entsprechend dem der Workbench unter Amigas OS 3.x, zu booten?

Wie bootest Du? Über das Early Startup Menu? Beim Booten per Bootblock wird standardmäßig AGA benutzt, wenn vorhanden. Der dafür zuständige Parameter ist 'A'. Ohne 'A' wird PAL/NTSC verwendet, ob dann ohne oder mit Interlace gearbeitet wird, weiss ich nicht.
Zitat:
Einzig der -S Bootparameter erzeugt einen schwer flimmernden aber immerhin sichtbaren Vidoemodus, der mittelfristg aber jeden Zeilentrafo eines RGB Monitors plättet.
'S' hat mit dem Grafikmodus nichts zu tun. Mit 'S' wird das Laden der Kernelsymbole veranlaßt.
 
gni   Nutzer

23.04.2007, 16:51 Uhr

[ - Direktlink - ]
Thema: streifen in der pal-anzeige auf vga
Brett: Amiga, AmigaOS 4

Zitat:
AmigaHarry:
Bei mir hat das mit TNG nie funktioniert, d.h. es wurde nie ins Flashrom der PIV geschrieben

Zu altes Flash? Ansonsten hast Du was falsch gemacht .-) Ich hatte mit TNG keine Probleme den FliFi zu programmieren.
Zitat:
erst aus dem Bootmenü war es dann möglich PAL und NTSC auf 71Hz zu bringen
Im Bootmenu kann man den Flickerfixer _nicht_ programmieren! Das geht definitiv nur mit TNG.
 
gni   Nutzer

20.04.2007, 08:40 Uhr

[ - Direktlink - ]
Thema: streifen in der pal-anzeige auf vga
Brett: Amiga, AmigaOS 4

Zitat:
Slay:
wie ich die zeilenfrequenz einstellen kann hab ich bisher auch nicht gefunden... muss ich dafür noch etwas zusätzliches installieren oder ist bei dem picasso96 paket ein programm dabei mit dem ich den flickerfixer konfigurieren kann und wenn ja, wo?

Der FlickerFixer wird mit PicassoModeTNG eingestellt. Wo man das herbekommt, weis ich nicht. Die Homepage von Picasso96 ist leider weg und im AmiNet ist das Archiv nicht.
 
 
1 2 -3- 4 5 6 7 8 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.