Suche - amiga-news.de Forum

amiga-news.de Forum > Suche

[ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste 2 3 4 5 6 -7- 8 9

Ergebnisse der Suche: 265 Treffer (30 pro Seite)

akl Nutzer

18.09.2007, 11:08 Uhr

[ - Direktlink - ]

Thema: Commodities.library - Übersicht input description strings ?
Brett: Programmierung

@thomas:

>Eine Volltextsuche in der commodities.library ergibt auch keine
>Treffer. Und da sind immerhin so Sachen wie PAGE_UP, PAGE_DOWN, BREAK
>etc. vorhanden.

Ich weiss ja nicht, in welcher Du gesucht hast - aber die v50.10 (3.4.2004) von MorphOS enthält alle die genannten Tags (in uppercase) und noch einige mehr, wie z.B. MEDIA1 bis MEDIA6.

akl Nutzer

17.09.2007, 23:27 Uhr

[ - Direktlink - ]

Thema: Samba 2.0.7 und Vista
Brett: Amiga, AmigaOS 4

Vielleicht hatte jemand schon das gleiche Problem?

Ich nutze seit Jahren Samba 2.0.7 aus dem Aminet - mit allen möglichen Windows-Versionen, inklusive XP. Leider funktioniert der Zugriff neuerdings mit Vista nicht mehr.

Dazu findet man in einschlägigen Foren den Tip, unter Vista
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa]
den LmCompatibilityLevel von 3 auf 1 zu setzen.

Leider bringt das rein gar nichts - unter XP ist dieser Wert 0, aber das Verhalten unterscheidet sich unter Vista bei Werten zwischen 0..3 lediglich in der Art des Fehlers (alles durchprobiert).

Ich nutze "security = user" und "encrypt passwords = yes" (was mit XP auch klappt) unter Samba und Standard-Einstellungen unter Vista Home Premium.

Da die MorphOS-Version von Samba im Aminet unbrauchbar ist (ausprobiert und verworfen) ist leider ein Update nicht so einfach...
Und die zweite 68k-Version ist unvollständig.

Ich sehe momentan nur folgende Möglichkeiten:

- die Einstellungen im Samba leicht modifizieren (möglichst weiterhin mit Security, viele Stellschrauben gibt es aber nicht)
- die Einstellungen in Vista weiter modifizieren (in Richtung XP)
- eine neue Samba-Version finden und installieren
- selber Samba neu portieren ;-)

akl Nutzer

17.09.2007, 10:48 Uhr

[ - Direktlink - ]

Thema: Commodities.library - Übersicht input description strings ?
Brett: Programmierung

@p-OS:
Das sieht stark nach Windows-Hotkeys aus (also neue Tags in Verwendung mit neueren Keyboards). Würde mich aber auch interessieren, ob und wo es vielleicht eine Liste neueren Datums gibt.

akl Nutzer

12.09.2007, 22:17 Uhr

[ - Direktlink - ]

Thema: Shell fernsteuern ?
Brett: Programmierung

@Holger:
sh ist bei ADE dabei, ein aktueller GCC ohne ADE und ixemul wiederum fast undenkbar...

akl Nutzer

12.09.2007, 22:13 Uhr

[ - Direktlink - ]

Thema: Shell fernsteuern ?
Brett: Programmierung

@Kaesebroetchen:

Möglicherweise ist der einzige Weg, die cis_#? Einträge des eigenen CLI vor dem Start von GCC umzubiegen - und danach wieder zurück.

akl Nutzer

12.09.2007, 21:59 Uhr

[ - Direktlink - ]

Thema: Shell fernsteuern ?
Brett: Programmierung

@Kaesebroetchen:

Sorry, es war nicht erkennbar, dass es um AROS geht. Dass 2>&1 & Co. selbst unter AOS/MOS nicht geht, habe ich allerdings eben auch ausprobiert...

akl Nutzer

12.09.2007, 16:00 Uhr

[ - Direktlink - ]

Thema: Shell fernsteuern ?
Brett: Programmierung

@Kaesebroetchen:

Ist es wirklich so, dass GCC SYS_Input/SYS_Output/NP_Error ignoriert?
Falls ja, liegt das nicht vermutlich an ixemul?
Falls ja, warum nicht einfach alles in eine pipe umleiten?

Kennt ixemul eigentlich das hier?

2>&1 Standardfehler auf den Deskriptor 1 (stdout) umleiten

akl Nutzer

08.09.2007, 19:12 Uhr

[ - Direktlink - ]

Thema: AIFF header manuell ändern
Brett: Amiga, AmigaOS 4

@DaxB:
Du kannst auch mal IFF-Arranger ausprobieren:
http://aminet.net/package/util/misc/IFF-Arr

akl Nutzer

18.08.2007, 11:46 Uhr

[ - Direktlink - ]

Thema: imsg zeug in C
Brett: Programmierung

@MaikG:

>Warum kann eine ULONG denn nicht einfach einen wert enthalten,
>welcher auf einen beliebigen Speicherbereich zeigt?

Ein ULONG kann tatsächlich eine Adresse beinhalten, weil Zeiger und ULONGs unter AOS beide 32 Bit breit sind - das wird z.B. bei TagItems auch gerne und häufig angewendet. Ein ULONG entspricht dabei in etwa einem typlosen Zeiger (APTR).

Bevor aber C bzw. der Compiler auf diese Adresse zugreifen kann, muss sie einen Typ bekommen - das geschieht in der Regel durch Typecasts, also z.B.

ULONG adresse = (ULONG) adresseL;
APTR pointer = (APTR) adresseL;

struct Gadget *gad = (struct Gadget *) pointer;

Wäre das nicht so, wäre das Risiko recht groß, dass man wild versucht, von Adressen Daten zu lesen, die dort überhaupt nicht vorhanden sind.

Bei Sprachen wie BCPL war das beispielsweise noch stärker der Fall.

Hin- und Her-Konvertieren zwischen ULONG, APTR und bestimmten Zeigern ist also kein Problem - wenn Du das "casten" jedoch vergisst, beschwert sich der Compiler. Zu Recht.

Die entsprechenden Fehler und Warnings sollte man als Hilfestellung begreifen, um eigene Fehler im Programmcode zu finden. Schließlich kann es sein, dass die ULONG-/APTR-Adresse die Du zu verwenden versuchst, überhaupt nicht zu einem Gadget gehört.

Je weniger Warnings, desto "sauberer" und potentiell fehlerfreier der Quellcode.

P.S.:
Natürlich geht auch jeder Unsinn in C, wie z.B.
struct Gadget *gad = (struct Gadget *) 0x12345678; // Peek($12345678)

[ Dieser Beitrag wurde von akl am 18.08.2007 um 11:47 Uhr geändert. ]

akl Nutzer

16.08.2007, 21:32 Uhr

[ - Direktlink - ]

Thema: AmigaOS '4+1' To Have Virtual Environment for AmigaOS 4 Apps
Brett: Amiga, AmigaOS 4

@aufdecker:

Also, ich habe noch keine APIs für MorphOS gesehen, mit denen ich vollwertige GUI-Applikationen programmieren könnte, die nicht im selben Shared Memory-Bereich wie normale 68k-/PPC-Applikationen laufen würden.

Und wie das bei OS4 ohne einen kompletten Schnitt bei allen möglichen APIs klappen soll, würde ich auch gerne sehen.

Das Problem ist ja bekannt und komplett durchdiskutiert:

- ohne Sandbox keine neuen, sauberen Konzepte (wegen Kompatibilität)
- mit Sandbox kein einfacher Nachrichten-/Datenaustausch zwischen beiden Welten

Sicher ist der Ansatz gut - aber durch große konzeptionelle Schnitte wird die Anwenderbasis erstmal nicht größer, sondern eher kleiner.

Zumal immer noch keine neue PPC-Hardware frei verfügbar ist, auf der ein frei käufliches AmigaOS4 laufen würde.

Ehrlich gesagt wüsste ich auf Anhieb jetzt auch nicht, welcher (andere) Embedded-Markt nach einem entsprechend angepaßten AOS4 verlangen würde.

akl Nutzer

15.08.2007, 11:46 Uhr

[ - Direktlink - ]

Thema: Partionsgröße in 64 Bit
Brett: Programmierung

@MaikG:
Du kannst die Funktion UMult64() aus der utility.library verwenden, müsstest Dir dann aber unter SAS/C per getreg() die oberen 32 Bit holen, also sowas in der Art:

ULONG result[2];

result[1] = UMult64(numblocks, blocksize);
result[0] = getreg(1);

In result[0] kannst Du die GBs oberhalb 4 GB ablesen und aus result[1] die restlichen MB/KB berechnen.

akl Nutzer

15.08.2007, 10:50 Uhr

[ - Direktlink - ]

Thema: Hat eigentlich Village Tronic auch andere Zusatzmodule Entwickelt?
Brett: Amiga, AmigaOS 4

@Neodym:
>Selbst wenn VillageTronic (VT) das wollte und auch die nötigen
>Unterlagen noch vorhanden wären, hätten sie ein Problem, weil einer der
>maßgeblichen Entwickler (Klaus Burkert) der Amiga-Produkte von VT vor
>einiger Zeit (viel zu früh) verstorben ist. Er hatte die
>Amiga-Kenntnisse und technische Brillanz - ihn zu ersetzen, dürfte sehr
>schwierig sein.

Am 04. April 2001, um genau zu sein, während er schon eine Weile für Metabox arbeitete.

Bei Fragen zur Hardware wäre es ggf. sinnvoll, sich an Tobias Seiler (siehe auch AROS) zu wenden.

akl Nutzer

12.08.2007, 12:30 Uhr

[ - Direktlink - ]

Thema: UAE *Multi Threadet* Wann?
Brett: AROS und Amiga-Emulatoren

@thomas:

>Ganz im Gegenteil. Programme, die die FPU benutzen, bestehen aus CPU-
>und FPU-Befehlen. Wenn für jeden FPU-Befehl ein Thread-Switch und
>anschließend noch einer gemacht werden müßte, wäre das ganze absolut
>lahm. Das ist ungefär so, wie eine GUI auf einem PPC-Amiga zu
>programmieren. Da kannst du zusehen, wie einzelne Linien gezeichnet
>werden. Genauso wäre das auch bei der FPU-"Auslagerung".

Das trifft sicher auf Binaries zu, in denen FPU-Befehle direkt vorkommen.

Eine mathieee-Library sichert jedoch z.B. vor Ausführung von IEEEDPDiv() eigentlich auch erst einmal alle 68k-Register und dann gibt es noch für jeden Task/Prozess einen eigenen FPU-Kontext, der zu sichern ist.

Allerdings wurde in der Richtung ja bereits optimiert:
http://aminet.net/package/util/libs/MathLibsUAE

akl Nutzer

12.08.2007, 12:21 Uhr

[ - Direktlink - ]

Thema: UAE *Multi Threadet* Wann?
Brett: AROS und Amiga-Emulatoren

@L-ED:

Eine singuläre FPU selbst in einen eigenen Thread auszulagern, könnte die beschriebenen Synchronisationsprobleme bringen, die dann wieder Overhead erzeugen.

Einen geringfügig anderen Ansatz fände ich vielversprechender:

- für jeden 68k-Task/Prozess Bedarf einen eigenen nativen FPU-Emulationsthread erzeugen (d.h. X-fache FPU-Simulation)
- diese Threads zusammen laufen ggf. auf einem eigenen Core
- das passt auch gut zu dem Ansatz der mathieee-Libaries unter AOS, wo ohnehin jeder Task/Prozess seine eigene Library-Base erhält (direktes Mapping auf einen der o.g. Threads)
- bei Libraries wie mathffp wäre zu analysieren, ob ein eigener singulärer Server-Thread Sinn macht

Natürlich müsste weiterhin eine Synchronisation stattfinden, allerdings könnte währenddessen ein anderer 68k-Prozess (und/oder sein FPU-Thread) ungestört weiterrechnen - d.h. kein Forbid/Permit.

Die Effizienzfrage stellt sich natürlich weiterhin, die Antwort könnte aber deutlich günstiger ausfallen.

akl Nutzer

11.08.2007, 16:26 Uhr

[ - Direktlink - ]

Thema: MorphOS und WLAN
Brett: MorphOS

@Arutha:
Ich denke schon - da der LAN-Port auch zur Konfiguration verwendet wird, ist er jedenfalls immer aktiv.
http://www.longshine.de/longshine/products/wireless/WA5-45/WA5-45-manual_ger.pdf

akl Nutzer

08.08.2007, 10:19 Uhr

[ - Direktlink - ]

Thema: MorphOS & SetPatch
Brett: MorphOS

@Holger:
Auf welche Graphics-Version sollten für OS 3.1 APIs entwickelte Programme denn Deiner Meinung nach überprüfen, wenn SetPatch >= 43.4 Bugs in der OS V40 (3.1) API fixt, ohne dabei die Majorversion zu ändern? Auf V50? Auf V41+? Was ist mit Programmen, die unter der 68k-Emulation von OS4 und MorphOS gleichermaßen funktionieren sollen? Und was ist mit binary-only Programmen, die nie an OS 3.5/3.9 angepasst wurden (mal ganz abgesehen davon, dass MorphOS nur zu 3.1 kompatibel sein will).

Die entsprechende Empfehlung in der SetPatch-Dokumentation, die OS-Version zu überprüfen bezieht sich leider eher auf Abwärtskompatibilität:

"First you must make sure that you are using the OS version that exhibits the bug to be fixed by SetPatch. Afterall a SetPatch V43 can't e.g. fix V39 bugs on a V37 based Amiga."

Klar, man könnte einfach auf graphics.library Version > 40 überprüfen und hoffen, dass dort der Bug nicht mehr drin ist. Eindeutig ist die Dokumentation jedoch nicht.

siehe auch
http://aminet.net/util/boot/SetPatch_43.6b.lha

Ich sehe daher SetPatch50 als Hack, solange bis jemandem etwas besseres einfällt, oder alle existierenden V40 68k-Programme sich korrekt verhalten und/oder an MorphOS angepaßt wurden. (Kann ja nicht mehr lange dauern... </ironie>)

akl Nutzer

07.08.2007, 20:52 Uhr

[ - Direktlink - ]

Thema: MorphOS & SetPatch
Brett: MorphOS

Mir ist aufgefallen, dass unter MorphOS kein c:SetPatch existiert, daher auch keine öffentliche SetPatch-Semaphore - und daher auch für 68k-Programme keine Möglichkeit zu erkennen, dass diverse Bugs in WritePixelLine/Array() der graphics.library V39/40 dort nicht mehr existieren.

Im Ergebnis laufen alle Programme langsamer, die korrekterweise einen Workaround für den Bug in den o.g. Funktionen implementiert haben - d.h. immer mit einer Kopie des Quellpuffers arbeiten, und somit u.U. Daten extra umkopieren müssen.

Ich würde alle MOS-User bitten, einmal den "SetPatch50"-Hack auszuprobieren, den ich vor kurzem ins Aminet hochgeladen habe, und um entsprechendes Feedback bitten, welche Programme dadurch schneller werden.

[ Dieser Beitrag wurde von akl am 07.08.2007 um 20:52 Uhr geändert. ]

akl Nutzer

31.07.2007, 13:52 Uhr

[ - Direktlink - ]

Thema: OS 3.9 ohne CD-ROM-Laufwerk installieren?
Brett: Amiga, AmigaOS 4

@Chritoph:
soweit ich weiss, laufen die OS-Patches alle über SetPatch, das auch einige ROM-Updates durchführt - es gibt jedoch keine unterschiedlichen SetPatch-Versionen für unterschiedliche Hardware

akl Nutzer

31.07.2007, 12:22 Uhr

[ - Direktlink - ]

Thema: OS 3.9 ohne CD-ROM-Laufwerk installieren?
Brett: Amiga, AmigaOS 4

@Chritoph:
z.B. die Festplatte des A3000 an Deinen A4000T anklemmen.

akl Nutzer

30.07.2007, 13:05 Uhr

[ - Direktlink - ]

Thema: MorphOS und WLAN
Brett: MorphOS

@Wishmaster:
Sehr konstruktiver Beitrag, danke ;-)

akl Nutzer

23.07.2007, 11:24 Uhr

[ - Direktlink - ]

Thema: FPU auch für Spiele Interssant?
Brett: Amiga, AmigaOS 4

@AMike:
Bitte widerlege an meine Adresse nichts, was ich nicht behauptet habe...

akl Nutzer

23.07.2007, 11:21 Uhr

[ - Direktlink - ]

Thema: FPU auch für Spiele Interssant?
Brett: Amiga, AmigaOS 4

gelöscht - ich geb's auf, hier irgendwem den Unterschied zwischen Fest- und Fließkomma-Arithmetik zu erklären

[ Dieser Beitrag wurde von akl am 23.07.2007 um 11:23 Uhr geändert. ]

akl Nutzer

23.07.2007, 10:55 Uhr

[ - Direktlink - ]

Thema: FPU auch für Spiele Interssant?
Brett: Amiga, AmigaOS 4

gelöscht, weil falsches Publikum

[ Dieser Beitrag wurde von akl am 23.07.2007 um 11:23 Uhr geändert. ]

akl Nutzer

17.07.2007, 17:16 Uhr

[ - Direktlink - ]

Thema: WinAROS Fragen
Brett: AROS und Amiga-Emulatoren

@Andreas_Wolf:

Offensichtlich war mein Fehler, dass ich nicht beide Originalquellen unmittelbar nachgelesen und erkannt habe, dass sich die beiden kryptischen Zitate (die dem Originalposter bestimmt auch ungemein weitergeholfen haben ;-) auf zwei unterschiedliche Dinge (68k-Binärkompatibilität/Portierbarkeit vs. 68k-Emulation) beziehen...

Konsequenterweise habe ich meine beiden Antworten nun gelöscht. (Das war einfacher, als über Spitzfindigkeiten zu streiten.)

Nichtsdestotrotz möchte ich kurz folgendes festhalten, damit vielleicht auch der Originalposter besser versteht, worum es geht.

- nein, WinAROS kann keinen 68k-Code ausführen
- dafür könnte man höchstens UAE innerhalb WinAROS als Amiga-68k-Emulator nutzen
- das wären dann jedoch weiterhin zwei verschiedene, logisch getrennte Systeme
- eine transp. 68k-Emulation innerhalb AROS selbst wäre u.a. aufgrund der Endian-Unterschiede zwischen 68k & x86 recht aufwändig (*)
- es sei denn, man wählt den gleichen Ansatz wie unter Amithlon (und hostet eine 68k-Version von AROS innerhalb dieser Emulation)
- leider wird seit geraumer Zeit die 68k-Version von AROS nur stiefmütterlich gepflegt und außer AfaOS existiert keine reale Testumgebung

Schönen Feierabend B-)

(*) AROS selbst ist jedoch Endian-neutral und problemlos portierbar

akl Nutzer

17.07.2007, 14:18 Uhr

[ - Direktlink - ]

Thema: WinAROS Fragen
Brett: AROS und Amiga-Emulatoren

[ Dieser Beitrag wurde von akl am 17.07.2007 um 17:06 Uhr geändert. ]

akl Nutzer

17.07.2007, 11:12 Uhr

[ - Direktlink - ]

Thema: WinAROS Fragen
Brett: AROS und Amiga-Emulatoren

[ Dieser Beitrag wurde von akl am 17.07.2007 um 17:06 Uhr geändert. ]

akl Nutzer

17.07.2007, 11:11 Uhr

[ - Direktlink - ]

Thema: WinAROS Fragen
Brett: AROS und Amiga-Emulatoren

[ Dieser Beitrag wurde von akl am 17.07.2007 um 17:06 Uhr geändert. ]

akl Nutzer

16.07.2007, 13:10 Uhr

[ - Direktlink - ]

Thema: MorphOS und WLAN
Brett: MorphOS

@RainMan:
Super :-) Falls sich das jemand nicht zutraut: bei TKR gibt es eine etwas teurere Version desselben Geräts, dafür aber mit Support und deutschem Handbuch. -- Praktisch finde ich an dem Gerät übrigens auch, dass es so klein ist.

akl Nutzer

11.07.2007, 19:27 Uhr

[ - Direktlink - ]

Thema: A1200 und TFT
Brett: Amiga, AmigaOS 4

Um es kurz zu machen:

Problem gelöst. Insofern VGAOnly beim Booten schon aktiv ist, gehen sowohl "DblNTSC Hires flimmerfrei" (nicht Interlaced) in 640x400 (nicht 480) als auch "MultiScan Productivity" (nicht Interlaced) in 640x480 an meinem "normalen" TFT.

DblNTSC synchronisiert aber wesentlich schlechter bzw. langsamer und verschmiert am Anfang sehr stark das Bild.

Laut Amiga-Monitorvoreinsteller sind die Frequenzen:

DblNTSC: 59 Hz, 29,2 kHz
Multiscan: 59 Hz, 31,44 kHz

Laut TFT-Anzeige sind es jedoch:

DblNTSC: 58,7 Hz, 29 kHz
Multiscan: 59,1 Hz, 31,1 kHz

bei 640x480 - vermutlich ist NTSC deshalb so verschmiert. Soviel auch zum Thema "VGAOnly zieht auf 31,5 kHz hoch" und Toleranzen im allgemeinen sowie in Relation zu Messwerten im Besonderen...

Dennoch werde ich mich nach einem TFT mit Scart-Eingang umschauen, einfach weil es das Umstöpseln erspart.

akl Nutzer

11.07.2007, 15:02 Uhr

[ - Direktlink - ]

Thema: A1200 und TFT
Brett: Amiga, AmigaOS 4

@Holger:
Ok, das mit den unsichtbaren Zeilen trifft *auch* auf VGA zu, das damit in gewisser Weise rückwärtskompatibel zu NTSC ist.

Dennoch gibt es Toleranzen:
http://www.cs.ucr.edu/~rmannion/CS179/VGATiming.pdf

Bevor ich das aber nicht nochmal ausprobiert habe, spare ich mir die restliche Diskussion ;-)

Erste 2 3 4 5 6 -7- 8 9

Ergebnisse der Suche: 265 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