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

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

Erste << 21 22 23 24 25 -26- 27 28 29 30 31 >> Letzte Ergebnisse der Suche: 2068 Treffer (30 pro Seite)
Holger   Nutzer

30.03.2008, 20:39 Uhr

[ - Direktlink - ] 		Thema: NAPALM Disskussion
Brett: Amiga, AmigaOS 4

Zitat:
Original von R-TEAM:
Eigentlich läuft das schon immer auf die selben Units raus ...
Napalm und alle anderen RT"S" Games haben keine verwendung für besonders
gut getarnte oder besonders leichte oder was weis ich noch sachen ..

Da zählt nur ->
Mehr panzerung
Mehr schußkraft
Möglichst Schnell
[und wenn es geht Billig ;) ]
Das hängt wohl damit zusammen, wie stark ein Spiel auf einen 1-Spielermodus zugeschnitten ist. Selbst bei nicht *RT*-S-Spielen versagen die Computerspieler ja sofort, wenn es darum geht, Spezialeinheiten, welcher Art auch immer einzusetzen. Und wenn es in einer Situation tatsächlich Einheiten gäbe, die durch eine andere Eigenschaft als Panzerung oder Schusskraft (wie z.B. Preis) einen berechenbaren Vorteil bieten können, dann produziert der Computerspieler eben davon so viele, wie es geht...

Wird dann ein Spiel so ausbalanciert, dass der Computerspieler trotz der Unfähigkeit zum cleveren Einsatz der meisten speziellen Einheiten noch halbwegs spielstark sein kann, dann ist klar, dass bei einem solchen Spiel auch im Zweispielermodus Tarnung, Brücken- oder Tunnelbau, Minen verlegen und sonst auch alles, was nur vom Menschen taktisch sinnvoll verwendet werden kann, kaum Vorteile bringt.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

16.03.2008, 18:14 Uhr

[ - Direktlink - ] 		Thema: Speichern d. Einstellungen Commoditie FKey
Brett: Amiga, AmigaOS 4

Zitat:
Original von gerograph:
Am besten in den Tooltypes speichern. Kopieren der Infodatei von 3.5 oder 3.1 hilft im überigen nicht.
Du musst auch drauf achten, dass für die .info Datei kein Schreibschutz gesetzt ist. Das siehst Du von der Workbench aus nicht, weil die die Attribute des Programms und nicht der .info Datei anzeigt. Einige CD-Rom Dateisysteme zeigen Dateien immer als nicht schreibbar (Flag w und d sind nicht gesetzt) an, und eine 1:1 Kopie erhält die Attribute.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

03.03.2008, 16:48 Uhr

[ - Direktlink - ] 		Thema: NAPALM auf AOS4 - Schon was Neues?
Brett: Amiga, AmigaOS 4

Zitat:
Original von MaikG:
SF ist geil. Sooo unwahrscheinlich ist das nicht. Die Dinosaurier
sollen ja auch von einem Asteroiden ausgerottet worden sein.
Es geht auch nicht um die potentielle Gefahr, sondern um die absurde "Lösung".

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

02.03.2008, 21:17 Uhr

[ - Direktlink - ] 		Thema: NAPALM auf AOS4 - Schon was Neues?
Brett: Amiga, AmigaOS 4

Zitat:
Original von MaikG:
Genauso gut kann uns eine Atombome auch mal den Arsch retten,
wenn ein großer Asteriod in richtung erde unterwegs ist.
Kann es sein, dass Du ein paar amerikanische Filme der schlechteren Art zuviel gesehen hast?

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

29.02.2008, 16:21 Uhr

[ - Direktlink - ] 		Thema: NAPALM auf AOS4 - Schon was Neues?
Brett: Amiga, AmigaOS 4

Zitat:
Original von Alchemy:
Geschmackloser Name für ein Strategisches Kriegs Spiel.
"Kriegs Spiel", egal ob Spielzeugpistolen, Computerspiel oder Fernsehfilm enthält so viel Geschmacklosigkeit, das es durch den Namen nicht wirklich wesentlich gesteigert werden könnte. Die wirklich deutlich größere Geschmacklosigkeit stellt die Existenz des Originals dar. Gegen diese zu protestieren, wäre wirklich sinnvoller, als sich über den Namen eines Spiels zu echauffieren.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

03.02.2008, 14:37 Uhr

[ - Direktlink - ] 		Thema: Programm testen
Brett: Amiga, AmigaOS 4

Ach so, NoAGA oder NoOCS wäre noch kürzer (wobei OCS dann nicht für Old Chipset, sondern für Original Chipset stehen würde).
 
Holger   Nutzer

03.02.2008, 14:34 Uhr

[ - Direktlink - ] 		Thema: Font-Grafiken gesucht
Brett: Amiga, AmigaOS 4

Zitat:
Original von cgutjahr:
Ach kuck mal an, juckt's dich doch noch in den Fingern ;-)

Und wie hast du die jetzt generiert?

Auf die schnelle zusammengehacktes Java-Programm mit dem oben beschriebenen Algorithmus:
  • Wählbarer Outline-Font mit wählbarer Textur rendern
  • Mit Farbverlauf gefülltes Outline rendern

    Jetzt fehlt eigentlich nur, die Hintergrundfarbe und den Outline-Farbverlauf auch wählbar zu machen, eine zusätzliche Korrektur, falls die Zeichen mit ihrer Original-Metrik nicht korrekt in ihren Boxen platziert sind, und die Textur optional auch mit einem Farbverlauf überblendbar zu machen.

    Vielleicht stelle ich das dann als Applet oder WebStart-Anwendung online...

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
    •  
    Holger   Nutzer

    03.02.2008, 14:28 Uhr

    [ - Direktlink - ]     		Thema: Programm testen
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von NoImag:
    Zitat:
    Dann dürften nur noch CGX-Screens verwendet werden.
    Aber eigentlich ist das der falsche Name, denn dann werden alle Screens genommen die nicht Nativ sind, bzw. nicht von den Customchips generiert werden. Ist auch noch eine Notlösung.
    ...
    Den Namen des Tooltypes finde ich nicht so schlimm. Es soll ja kurz sein, nehme ich an :) Ansonsten könntest Du es NoAmigaGfx nennen. Im Menü wäre "Nur auf Grafikarte" eine Möglichkeit.
    Wenn man weder CGX, noch P96 explizit meint, wäre der übliche Name RTG. OnlyRTG wäre als Name genauso kurz.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    01.02.2008, 23:13 Uhr

    [ - Direktlink - ]     		Thema: Font-Grafiken gesucht
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von scholly:
    Zitat:
    Aus dem Bild, das du verlinkt hast, geht das Format eindeutig hervor: Die 60 Zeichen von ASCII 32 bis ASCII 91 mit einer Größe von 32x32 Pixeln "hintereinander" in einer Bitmap.
    Nun, das war ein Beispiel für 32er Fonts, das auch noch unvollständig war und es gibt so Bitmaps auch für 8er und 16er Größe.
    Das ist aber trivial genug. Die interessante Frage ist ja, wofür das nun wirklich sein soll. Beim DemoMaker von RedRector lag mit Sicherheit eine Beschreibung der Anforderungen bei, zumindest bei der Original-Version 8o

    Zitat:
    Zitat:
    Mit einem einfachen ARexx-Skript lässt sich sowas in PPaint automatisieren (Color Font öffnen, die 60 Zeichen in die Bitmap schreiben), würde mich nicht wundern wenn's sowas bereits im Aminet gäbe.
    Solange ich keine entsprechende Formatbeschreibung in die Finger bekomme, laß ich von solchen zeitintensiven Experimenten die Finger.

    Zeitintensiv ist relativ.
    So auf die schnelle hab ich mal was generiert, das man noch nachbearbeiten müsste, aber schon zeigt, dass man keine Ewigkeiten dafür braucht...

    http://www.math.tu-berlin.de/~pietsch/font/

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    01.02.2008, 19:42 Uhr

    [ - Direktlink - ]     		Thema: Font-Grafiken gesucht
    Brett: Amiga, AmigaOS 4

    Ja, so etwas war damals der Inbegriff von Kreativität--heute ließe sich das bestimmt relativ einfach automatisieren: Outline-Font laden, Pattern-laden, Buchstaben mit Pattern rendern, 3D-Kanten hinzufügen, evtl. noch ein paar Filter drüberjagen... Also, im Prinzip das, was Candy Factory mit Schwarz-Weiß BitMaps gemacht hat. Wenn man jetzt noch ein Programm oder ein ARexx-Skript für PPaint hätte, das die Buchstaben in der gewünschten Anordnung in eine Schwarz-Weiß BitMap rendert, würde diese Kombination schon Fonts in der üblichen Qualität möglich machen.
    Von diesem Schema wichen die wenigsten Font-Designs ab, und von denen waren wiederum die wenigsten besser als das Übliche.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    01.02.2008, 10:55 Uhr

    [ - Direktlink - ]     		Thema: Programm testen
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von NoImag:
    @Ralf27:
    Ich habe jetzt nochmal mit der DirScan-freien Version getestet. Der größte Teil der von mir beobachteten Probleme mit dem Optionen-Menü sind darauf zurückzuführen, dass irgendetwas die Menüs zerschießt. Dies ist jedoch nicht das DirScan! Die Probleme treten auch mit der DirScan-freien Version auf, allerdings abhängig davon, was sonst noch so läuft.

    Frage an Ralf27:
    Du benutzt doch nicht etwa mit SADD() ermittelte String-Adressen für die Erzeugen der Menüs?

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    31.01.2008, 21:21 Uhr

    [ - Direktlink - ]     		Thema: 68060rc50 keine mmu?
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von Michael_D:
    spätestens wenn Setpatch die 68060.library geladen hat, ist
    die MMU in Gebrauch um die 882-Emu zu etablieren.
    Für die 882-Emulation braucht man keine MMU. Die Emulation von CoProzessoren ist im 68k Prozessor grundsätzlich vorgesehen.
    Zitat:
    Man kann mit der MMU auch einige Adressbereiche z.B. vom Superscalar-
    oder beim 040er CopyBack-Modus auszuschließen.
    Wer macht denn so was?

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    04.01.2008, 19:10 Uhr

    [ - Direktlink - ]     		Thema: AWEB
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von MaikG:
    Das sagen immer die, die denken es gibt überall DSL...
    Blödsinn. Ich benutze meistens ein 56k Modem. Und wir reden hier trotzdem über einen Unterschied von 0,0001% in der Datenmenge.
    Zitat:
    >Übrigens sind zwei byte für ein ö immer noch weniger als & o u m l ;
    >und da hat sich ja nu auch niemand drüber aufgeregt.

    Ja, wo man das benutzt. Ich benutze immer den Amiga-Ascii code
    in HTML Seiten.
    Schön für Dich. Amiga-News hat das ö jetzt mehrfach als & o u m l ; zu Dir übertragen, ohne dass Du es bemerkt hast 8o

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    04.01.2008, 17:24 Uhr

    [ - Direktlink - ]     		Thema: AWEB
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von MaikG:
    Warum die Seitenbetreiber sowas machen auch nicht, da werden
    immer 2 Zeichen statt 1 Zeichen übertragen - zumindest auf Deutsche
    Seiten ist das sinnloser overheat.
    Ich glaube nicht, dass die paar Bytes wirklich die Server überhitzen. Falls Du aber overhead meinst, der ist, angesichts von ein paar Bytes auf mehrere kByte Text ein Witz. Vor allem, wo ein kleines Bild ausreicht, um die Datenmenge einer Webseite um Faktor 100 zu erhöhen.

    Übrigens sind zwei byte für ein ö immer noch weniger als & o u m l ; und da hat sich ja nu auch niemand drüber aufgeregt.

    Was Unicode für Vorteile bringt, wirst Du allerdings nie erfahren, solange Du UTF-8 codierte Seiten lediglich via Filter zu ISO-LATIN-x konvertiert betrachtest.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    19.12.2007, 19:39 Uhr

    [ - Direktlink - ]     		Thema: warpup oder phase5?
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von Solar:
    Ich muß zu meiner Schande erkennen, daß die Benamsung "WarpOS" tatsächlich komplett an mir vorbeigegangen ist. In meiner Erinnerung war das immer WarpUP.

    Ob WarpUP oder WarpOS ist relativ egal, WarpHack hätte es besser getroffen...

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    18.12.2007, 16:25 Uhr

    [ - Direktlink - ]     		Thema: os3.9 vs. os4
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von Der_Wanderer:
    Und AfA behauptet auch nicht ein OS zu sein. AfA OS => "AROS für AmigaOS". Es ist also eine Extention für AmigaOS, die nach und nach kompletter wird und möglicherweise AmigaOS irgendwann ablöst, bzw. zu AROS wird.

    Und warum schreibst Du dann AfA_OS und nicht, wie es also korrekt wäre, AfAOS oder A_f_AOS oder Af_AOS?

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    18.12.2007, 13:22 Uhr

    [ - Direktlink - ]     		Thema: OS 4 - Erfahrungsberichte
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von ZeroG:
    Mit virtuellem Speicher sind die Speicheraddressen die du als Programm siehst nicht mehr gleich der realen Speicheraddresse die z.B. der SCSI-Chip sieht, richtig.

    Ausgenommen ist nur die AbsExecBase die ja immer an der gleichen Addresse zu finden sein muß und, wenn ich richtig vermute, die Register der Customchips/ChipRam.
    MMU-basierter virtueller Speicher arbeitet seitenbasiert und unterstützt keine einzelnen Adressen. Es muss zwar aus Kompatiblitätsgrunden sicher gestellt werden, dass 68k Programm die ExecBase an der Adresse 4 finden, aber die laufen eh in einer Emulation.

    Da der Rest der Zero-Page eigentlich für Anwendungen tabu ist, bietet es sich eher an, diese Seite zu sperren, und im Exception-Handler zu prüfen, ob es sich um Adresse 4 handelt, und für diese dann einen erfolgreichen Zugriff zu simulieren. So ähnlichen machen es imho auch die Tools, die auf dem 68k illegale Zugriffe überprüfen.

    Letztendlich könnte für jede Anwendung die Adresse vier an einer anderen physikalischen Adresse liegen. Es muss nur die ExecBase an dieser Stelle gespeichert sein...

    Zitat:
    Original von TetiSoft:
    Wenn man vom Chip schaufelt ist es gar kein DMA mehr.
    Auch unter OS3 ist echte DMA-Übertragung in den Puffer
    der Anwendung nicht immer möglich, es gibt Restriktionen
    bezüglich des Alignments mit den Cachelines der CPU.
    Ich weiß nicht wie andere Betriebssysteme es machen,
    kann mir aber vorstellen daß es auch welche gibt die
    umkopieren und es trotzdem DMA nennen, und der SCSI-Chip
    ist bestimmt auch dieser Meinung.
    DMA ist es eben immer, solange die CPU nicht die Daten vom IO-Baustein empfangen muss. Im letzteren Fall müsste sich die CPU mit dem IO-Baustein synchronisieren, entweder durch Anpassung ihres eigenen Takts oder durch einen Interrupt pro Datenwort. Beides übelste Performance-Killer, gegen die der Zeitaufwand für eine einzelne, nicht unterbrochene Kopieraktion gar nichts ist.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    07.12.2007, 12:22 Uhr

    [ - Direktlink - ]     		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von TetiSoft:
    So rein gefühlsmäßig wäre Speicherschutz für Code und als "const"
    deklarierte Daten auch bei 68k-Programmen wichtiger als daß ein
    68k-Programm selbst MMU-Funktionen aufrufen kann.
    Um das ging es ja in erster Linie. Spezielle, weitergehende Logik macht bei 68k-Programmen nicht viel Sinn, da die anderen 68k-Systeme ja auch nichts vergleichbares anbieten.
    Zitat:
    Es würde sich anbieten, neue Hunk-Typen wie "ROCODE" und "RODATA" einzuführen, aber die existierenden 68k-kompatiblen Betriebssysteme alle zu erweitern oder sich überhaupt erstmal zu einigen ist vermutlich nicht machbar.
    Ich glaube auch nicht, dass eine Erweiterung von AOS3.x von Hyperion gewollt wäre. Solche Backports wurden auch für andere Features bislang nicht in Erwägung gezogen. Andersherum ist eine Erweiterung des Hunk-Formats für (neue) 68k-Programme auch nicht gewollt, wenn ein solches Programm AOS4 benötigt, also auch für ppc übersetzt werden könnte.

    Deshalb sind neue Hunk-Typen keine gute Wahl. Eine vom 68k-Programm aufrufbare Funktion oder ein Flag in einem bislang unter AOS3.x unbenutzten Bereich wäre die bessere Wahl.

    Ich würde sowieso begrüßen, wenn es eine solche Standard-Möglichkeit gäbe, ein paar Meta-Informationen über das Programm abzulegen.
    In der Art:

    Flag-Bit:
    0 - Aufruf aus der Shell unterstützt
    1 - Aufruf von der Workbench unterstützt
    2 - Code-Hunk darf schreibgeschützt werden
    3 - Resident möglich (keine Veränderung/Verlust der Information durchs Dateisystem mehr)
    4-6 - 000 Anwendung, 001 Library, 010 Device, 011 DOS-Handler, 100, KeyMap, 101 Font, etc.

    Man könnte sich noch andere Meta-Informationen vorstellen, benötigte Stack-Größe, Sachen, die eigentlich nicht verloren gehen sollten, wenn das Icon nicht mitkopiert wird (bzw. eigentlich nicht vom Endanwender manipulierbar sein sollten) oder auch zwingend benötigte Libraries als vorab-Information, um gar nicht erst das Programm starten zu müssen, nur um zu erfahren, dass etwas fehlt.

    Wenn man bei dem alten Prinzip bleibt, das solche essentiellen Informationen im Icon gespeichert werden, kann man natürlich auch einfach ein neues ToolType einführen "ProtectCode". Das wäre am einfachsten.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    07.12.2007, 11:58 Uhr

    [ - Direktlink - ]     		Thema: OS4 Allgemeine Probleme+Fragen
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von TetiSoft:
    Aus dem Stehgreif fällt mir keine ein, vielleicht gibts ja bei
    ListBrowsern eine Begrenzung auf 64kB Einträge, müßte mal jemand
    ausprobieren.
    List-Gadgets selbst hatten imho unter AmigaOS keine Beschränkung, was die Anzahl Einträge angeht. Aber bis einschließlich AOS3.9 verwendeten die Proportional-Gadgets, die die zugehörige ScrollLeiste implementieren, intern 16 Bit-Variablen. Also, ab MAX_SHORT / Zeilenhöhe könnte es Probleme geben. Das hängt aber natürlich von den Details ab, wie der Frage, ob die Werte signed interpretiert wurden, oder ob das jeweilige List-Gadget die proportionalen Werte aus den Pixel-Größen (notwendig, wenn Zeilen unterschiedliche Höhe besitzen dürfen) oder nur aus der Anzahl Einträge generiert.

    Da könnten sich gadtools, MUI und ReAction unterscheiden. Und natürlich könnten die AOS4-Versionen alle in dieser Hinsicht überarbeitet worden sein. Aber wenn das Proportional-Gadget in dieser Hinsicht nicht überarbeitet wurde, gibt es spätestens ab 64ki Einträge Probleme, wie gesagt, im worst case aber schon deutlich früher (ab 32ki/Zeilenhöhe in Pixel)

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    06.12.2007, 13:34 Uhr

    [ - Direktlink - ]     		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von TetiSoft:
    Nein. Ein Programm was das machen würde sollte besser auf OS4 getestet
    werden bevor man es in Umlauf bringt, und dann kann man ja gleich
    eine PPC-Version testen wo es den Unterschied zwischen .data und
    .rodata Sektionen sowieso gibt.
    Hmm, ich dachte eher daran, dass man vielleicht auch ohne AOS4 so viele Plattformen wie möglich unterstützen will, und eine Operation, die man unter 68k sonst via mmu durchführen würde, beim Erkennen von AOS4 ans OS delegiert. Nun ja, in den meisten Fällen läuft ein sauberes Programm ohne diesen Schutz ja auch fast so gut wie mit...
    Zitat:
    Ein Programmierer der weiß was er tut kann Funktionen aufrufen
    um z.B. Speicherbereiche schreibzuschützen oder Exception-Handler,
    Task-Trap-Handler usw. installieren.
    Aber das kann man nicht via mmu.library zur Verfügung stellen, da 68k-Software diese Funktionen nicht aufrufen kann, richtig?

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    06.12.2007, 13:11 Uhr

    [ - Direktlink - ]     		Thema: maximale ide plattengroesse am amiga
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von akl:
    Wie man überall sieht, verwendet außer der politisch korrekten Wikipedia und dem wissenschaftlichen Bereich alle Welt weiterhin kB und MB anstelle von KiB und MiB. Vielleicht weil "Gibibyte" irgendwie albern klingt. Vielleicht, weil sich per Federstrich alte Gewohnheiten eben nicht so einfach ändern lassen (siehe Rechtschreibreform).
    Nicht nur das.
    Ich kenne seit meiner Kindheit die Bezeichnung kB, die Ka-Byte gesprochen wird, und somit in der Aussprache deutlich vom Kilo unterschieden wird. Und bin mit dieser Aussprache noch nie irgendwo auf Unverständnis gestoßen. Kann mich auch nicht erinnern, jemanden "Kilobyte" sagen zu hören, außer vielleicht Escom-Verkäufer oder so...

    Da fällt es einem natürlich schwer, jetzt von oben diktiert "KiByte" zu schreiben für etwas, dass man von Kindesbeinen an "KaByte" gesprochen hat.

    Es ist auch nicht verständlich, warum alle Vorsilben (kibi mebi gibi tebi) exakt so anfangen lässt, wie die Vorsilben, von denen sie sich unterscheiden sollen, die sich im Falle von "ki" und "gi" noch nicht ein mal in ihre Abkürzung eindeutig von der 10³/10⁹ unterscheiden. Jemand der kB kennt (und für "Kilobyte" hält), wird niemals von selbst auf die Idee kommen, dass mit kiB etwas klar anderes gemeint ist.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    06.12.2007, 12:43 Uhr

    [ - Direktlink - ]     		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von TetiSoft:
    68k CODE, DATA und BSS Segmente sind aus Kompatibilitätsgründen
    NICHT schreibgeschützt! Es gibt zu viele 68k Programme die z.B.
    Stringkonstanten im CODE Segment haben und diese dann auch noch
    zur Laufzeit ändern wollen, sie dürfen das nach wie vor.
    Gibt es eine Möglichkeit für 68k-Programme, unter AOS4 eine strengere Kontrolle für sich selbst zu beantragen? (Eine Art Speicherzugriffs-FSK, sozusagen)
    Zitat:
    Original von whose:
    Und Du hast die Beschreibung des OS4 JIT nicht gelesen. Er emuliert einen 68040 (bis auf wenige Instruktionen und hat keine MMU), meldet aber aus Kompatibilitätsgründen einen 68020. Der JIT an sich ist wirklich schnell genug. Starte ein für 040 optimiertes Programm darauf und Du wirst sehen, daß es funktioniert (sofern es sauber geschrieben wurde).
    Oder es nimmt die Meldung beim Wort und bringt eine Fehlermeldung, dass es einen 68040 benötigt.
    Zitat:
    Original von Solar:
    Es gibt keine Möglichkeit, eine "Mitbenutzung" der MMU zu ermöglichen, ohne den kompletten Speicherschutz des OS auszuhebeln.
    Nun ja, den meisten Programmen dürfte es weniger darum gehen, die MMU direkt programmieren zu können, sondern bestimmte Features zu verwenden. Sei es, beim Zugriff auf einen bestimmten Speicherbereich (in ihrer eigenen Anwendung) informiert zu werden, oder darauf aufbauend, virtueller Speicher oder Memory Mapped IO oder eben, um die Regeln für den eigenen Speicher noch zu verschärfen. Wenn eine Bibliothek das anbieten würde (was andere Betriebssysteme auch anbieten), sehe ich da keine Probleme.
    Zitat:
    (Es sei denn, der Speicherschutz beim PPC sei wesentlich anders implementiert als auf x86 oder Sparc.)
    Hmm, also die 6xx_Reihe dürfte noch keine Virtualisierungsfunktionen besitzen ;)

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    06.12.2007, 12:33 Uhr

    [ - Direktlink - ]     		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von MaikG:
    Was heisst jenseits? Ich habe mind. 3 hier die machen das.
    Mittels degrader wird ein höher Priorisierter Task erzeugt,
    welcher soviel CPU-Zeit klaut das es in 68000 Geschwindigkeit
    läuft.
    Jenseits heißt 68020, 68030, 68040 oder 68060. Eben nicht 68000. Also auch kein Degrader, um 68000 Software auszuführen, denn von 68000-Software wollten wir hier nicht reden, und ein Degrader ist kein Selbstzweck.

    Schließlich diskutierst Du ja gerade über die so sinnvolle Frage, ob nun ein 68020 oder ein 68060 emuliert werden soll.
    Zitat:
    Das hat der eine hier doch schon erwähnt das manche Progs
    annehmen wenn a so und so lange braucht das beim nächsten mal
    auch so sein muss, ggf. beim JIT aber nicht so ist.
    Und dass solche Software seit dem 68020, eigentlich schon seit dem Erscheinen von 68010- und 14MHz 68000-Beschleunigern nicht mehr funktioniert.
    Ob das Flag in der Exec-Base einen 68060 ausweist oder einen 68020, spielt für solche Software keine Rolle.
    Zitat:
    Ach ich soll mit einem Programm auf UAE spielen welches nichtmal auf echten Amigas die richtigen werte zeigen?
    Ist mir klar das ein Benchmark unter UAE nicht unbedingt korrekt ist,
    auch mit Programmen die sonst Funktionieren.
    Aha! Du siehst also ein, dass das Timing in einer Emulation (vor allem mit JIT) nicht korrekt ist. Was diskutierst Du dann hier überhaupt so sinnlos rum?!

    Du hast übrigens offensichtlich den Witz dabei nicht kapiert. Du darfst gerne jede beliebige Software benutzen, meinethalben eine, von der Du meinst, dass sie die Taktfrequenz auf einem echten Amiga richtig errechnet:
    Wie Dir vielleicht noch nicht aufgefallen ist, gibt es beim UAE überhaupt keine "richtige Taktfrequenz". Die einzige einstellbare exakte Taktfrequenz ist "Match A500 Speed", die logischerweise nur beim emulierten 68000 (und somit ohne JIT) funktioniert. Alle anderen Prozessoreinstellungen besitzen überhaupt keine Möglichkeit einer justierbaren Taktfrequenz und somit auch kein korrektes Timing im Sinne der Prozessorgeschwindigkeit. Wenn es auch nur ein relevantes Programm gäbe, dass nicht für den A500 geschrieben wurde (Siehe "Match A500 Speed") und von einer bestimmten Prozessorgeschwindigkeit ausgeht, hätte sich schon jemand beschwert.
    Zitat:
    >Nenn mir eine Software, die nachgewiesenermaßen eine Zählschleife
    >besitzt und sowohl unter 68020 und 68040 korrekt funktioniert.

    Ohne weiteres auf 020/040.
    Meine Türsprechanlage. Duck und wegrenn.
    So so. Du rüstest auf PPC und AOS4 auf, nur um damit eine Türsprechanlage zu betreiben? Na, dafür wirst Du wohl auch eine angepasste AOS4-Version Deiner Zählschleifen implementieren können...

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    05.12.2007, 13:37 Uhr

    [ - Direktlink - ]     		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von Solar:
    Wer nicht weiß, was es mit SimCity auf sich hat - das Spiel verließ sich auf ein nicht dokumentiertes, unsauberes Verhalten der Speicherverwaltung. Als eine neuere Version von Windows dieses Verhalten inkompatibel änderte, hat Microsoft extra eine Erkennung eingebaut, die bei "simcity.exe" extra das alte Verhalten wieder aktivierte, um das damals beliebteste Spiel nicht "abzuschießen".
    Das ist aber nur die Spitze des Eisbergs. Windows besitzt von Hause aus eine riesige Anzahl von Hacks für spezielle Programme.
    Wie z.B.
    http://blogs.msdn.com/oldnewthing/archive/2007/11/16/6281925.aspx
    oder (schon geradezu lustig)
    http://www.microsoft.com/technet/technetmag/issues/2006/10/WindowsConfidential/

    Natürlich kann man auch mal ein "nacktes" WindowsXP installieren und dann in der Registry nachschauen, für wie viele Programme dort Einstellungen hinterlegt sind, die noch nie auf dem System installiert oder ausgeführt wurden...

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    05.12.2007, 13:00 Uhr

    [ - Direktlink - ]     		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von MaikG:
    Richtig. Ich sagte schon das "warte zyklen" keine saubere
    Programmierung ist - ist aber nunmal vorhanden.
    Aber viele Programme treffen die entscheidung welcher
    Code verwendet wird. Und dabei Spielt es keine rolle ob
    der 020er nun 14 MHZ oder 50 MHZ hat.
    Ich bezweifle, dass es außer vielleicht Deiner eigenen irgendeine Software für Prozessoren jenseits 68000 gibt, die sich eines wartezyklenbasierten Timings bedienen.
    Wie sollte das bitteschön funktionieren? Der 68020 wurde mit ~14 und ~28 MHz, und, wenn ich mich recht entsinne, auch auf weniger verbreiteten Board mit ~7 und 33 MHz verbaut, der 68030 mit so vielen unterschiedlichen Taktfrequenzen, dass es gar keinen Sinn hätte, die alle aufzuzählen. Und dummerweise hängt die Ausführungsgeschwindigkeit auch davon ab, ob sich das Programm im a) Chip-RAM, b) Pseudo-FastRAM oder echtem FastRAM c) auf dem Mainboard, d) auf der Turbokarte, e) auf einem ZII-Board, f) auf einem ZIII-Board und g) bei der ersten Ausführung schon im Cache befindet oder auch nicht.

    Und Du willst mir erzählen, dass da draußen irgendeine Software existiert, die unter diesen Umständen eine exakte Ausführungsgeschwindigkeit für eine Schleife vorhersagen kann?

    Kleiner Tipp: lass Dir mal von SysInfo in UAE bei aktiviertem JIT die Taktfrequenz anzeigen. Darfst Du gerne für verschiedene Prozessoren ausprobieren.
    Zitat:
    Mit Forbid/Permit ist es auf 68K genau genug. Unter dem
    JIT kann ich das nicht sagen. Aber der Code würde nicht 5 Sekunden
    statt 5 Minuten laufen durch solche abweichungen - nur bei der
    falschen Prozessor Angabe.
    Nenn mir eine Software, die nachgewiesenermaßen eine Zählschleife besitzt und sowohl unter 68020 und 68040 korrekt funktioniert. Bzw., die sowohl auf einem 68020 mit und ohne echtes FastRAM korrekt funktioniert.

    Zitat:
    Gut, wieder etliche Kandidaten gekillt.
    Warum kann ich innerhalb einer Emulation den Datencache nicht
    ausschalten? Da ist doch OS4 nicht von betroffen?
    Du möchtest, dass Deine Software mit JIT funktioniert. Was denkst Du, was ein JIT macht? Er erzeugt native Code für 68k-Code, was prinzipiell nichts anderes als eine Art Cache ist. Der erzeugte native Code ist ein Cache für den auszuführenden 68k-Code. Jedes Programm, dass damit Probleme hat, weil es z.B. seinen 68k-Code ändert, aber keinen Cache-Flush durchführt, wird immer Probleme mit einem JIT haben.
    Zitat:
    Den VBR-Register darf ich dann auch nicht nach 0 setzten?
    Du kannst den VBR hinlegen, wo Du willst, Interrupts funktionierten sowieso nicht mit dem JIT, sondern werden interpretiert. Das hatten wir bereits (Du weißt, wozu der VBR dient?). Und Spiele, die viel mit Interrupts machen, werden demzufolge auch nicht mit zufriedenstellender Geschwindigkeit laufen.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    29.11.2007, 11:15 Uhr

    [ - Direktlink - ]     		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von tboeckel:
    Wann lernen es die Programmierer endlich mal den offiziellen Weg zu gehen? Nur weil unter AmigaOS früher viele Hacks problemlos möglich waren ändert das nichts an der Tatsache, daß es Hacks waren, sind und bleiben werden, die unerlaubte Abkürzungen gehen und deswegen unter zukünftigen OS-Versionen scheitern müssen, weil der Trampelpfad zu einem Abgrund wurde. Aber das aus gutem Grund!
    Nun, ein ziemlich gewichtiger Grund dürfte wohl auch darin liegen, dass selbst die Beispiel-Programme von Commodore eine Sammlung von Beispielen, wie man es nicht machen sollte waren. Und viele Sachen konnte(kann) man auch nicht auf system-konforme Weise machen, weil die entsprechende Funktionalität einfach fehlt(e).

    Erst bei AOS3.0 wurde z.B. AllocBitMap eingeführt, ein AllocRastPort gibt es selbst in AOS4.0 immer noch nicht. Da braucht man sich über Annahmen von Programmierern ("eine RastPort-Struktur hat immer n bytes") gar nicht zu wundern...

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    28.11.2007, 21:30 Uhr

    [ - Direktlink - ]     		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von ZeroG:
    Spontan könnte man sich einfach mal die "struct Window" definition in intuition/intuition.h ansehen, ist seit Eoenen da drin.

    Äonen</klugscheiß>

    Ergänzend sei noch angemerkt, dass man seit OS2.0 das Fenster mit InnerWidth/InnerHeight öffnen kann, wodurch die Rahmengrößen automatisch hinzugefügt werden. Somit kann man also den Platzbedarf für den Inhalt errechnen, Fenster öffnen und dann die Größen aus der Window-Struktur berücksichtigen.

    Prinzipiell stehen die Größen auch in der Screen-Struktur. Davon sollte man aber keinen Gebrauch machen, da die tatsächlichen Größen davon abweichen können (wenn Gadgets in den Rahmen sind), und es auch der (eventuellen, zukünftigen) Möglichkeit, Rahmengrößen per Task festzulegen, zuträglich wäre, wenn man nur die Werte im eigenen Fenster verwendet.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    28.11.2007, 21:21 Uhr

    [ - Direktlink - ]     		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von TetiSoft:
    Manche Programme lesen z.B. einfach ein Register
    der CIA aus, da weiß man daß es eine Verzögerung von soundsoviel
    Nanosekunden bewirkt. Wenn das Programm stattdessen einen Ansatz
    wie "Warte 6 NOPs auf 68000, 4 NOPs auf 68020, ..." benutzen würde
    (Keine Ahnung ob es das wirklich gibt), würde das mit JIT nicht
    funktionieren (und ohne JIT auch nur wenn der Emulator in etwa
    die gleiche Geschwindigkeit hat wie der echte 68k).
    Solcherart Software gibt es zum Glück wirklich sehr selten auf dem Amiga. Diese ist ja daran zu erkennen, dass auch schon einer neuerer "Classic"-Amiga ihr Probleme bereitet. In WinUAE würde eine solche Software auch nur im cycle-exact Modus laufen, und der funktioniert nicht mit dem JIT.

    Das ist kein prinzipielles Problem eines JITs. Man könnte ihn auch so designen, dass das Timing (bei UAE inkl. Chipset) integraler Bestandteil der Emulation wäre. Das Resultat wäre aber ein drastischer Performance-Verlust bei den Programmen, die das nicht brauchen (also 99,9%).

    Der JIT von WinUAE besitzt auch andere, potentiell nicht kompatible Verallgemeinerungen, wie z.B. die Annahme, das eine Instruktion, die die Custom-Chips (nicht) anspricht, es bei der nächsten Ausführung wieder (nicht) tun wird.

    Genau deshalb gibt es ja die Möglichkeit, Software auch ohne JIT auszuführen, damit der JIT genau das bewerkstelligen kann, wozu er entwickelt wurde: die Software zu beschleunigen, bei der es möglich ist.

    Es wäre wahrscheinlich auch möglich, einen speziellen JIT zu entwickeln, der nur bei Interrupts Verwendung findet. Allerdings mit einem zweifelhaften Aufwand/Nutzen Verhältnis. AOS4 soll letztendlich ein ppc-OS sein, und keine 68k-Emulatorbox.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    27.11.2007, 11:34 Uhr

    [ - Direktlink - ]     		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von TetiSoft:
    > Ich meine das muss schon in der Werbung stehen wenn dieses
    > OS extremer als OS2.0->3.9 abweicht.

    Ich dachte daß die bloße Tatsache daß es jetzt ein PPC-OS ist
    einem schon klarmacht daß es ein ziemlicher Unterschied zu OS3.9
    sein muß.

    Das dachte ich bislang auch...

    Zitat:
    Original von MaikG:
    Letztendlich wird es dadurch keine gleichwerige Ersatz-Software
    für nicht laufende Software geben. Und dann geht OS4 vielleicht
    schneller unter als es entstand...
    Wer auf dem Grund steht, kann nicht untergehen...
    Zitat:
    Siehe oben.
    Die Speicherverwaltung war gut so wie sie war.
    Wohl kaum.
    Schon zu Commodore wurde daran rumgedoktort, mit dem Versuch, die offensichtlichen Schwächen zu umgehen. Aber die Dokumentation des neuen Systems ist ja öffentlich einsehbar, und dann gibt's noch das TLSFMem, das eine Verbesserung im alten AOS3.x versucht--das alles, weil die Speicherverwaltung "gut so wie sie war" ist?
    Zitat:
    Hätte man die Sources von OS3.9(ich weiss hatte man nicht)
    nur auf PPC-Portiert, nicht ohne Grund drin rumgepfuscht und
    einen JIT hinzugefügt währe das Ergebniss besser als jetzt.
    Hätte man die Sourcen von OS3.9 gehabt, hätte man das vielleicht machen können, und es wäre eventuell schneller gegangen, besser wäre es definitiv nicht geworden, schließlich war OS3.9 schon Pfusch, und Gründe, etwas zu ändern, gab es genug.
    Zitat:
    Das sagst du mir einige Tage nachdem ich schon bezahlt habe...
    Wer nach allem, was geschehen ist, noch im voraus bezahlt, hat's nicht anders verdient.

    Zitat:
    Original von MaikG:
    Die WOS Bugs halten sich stark in grenzen, wenn dann gibts nal 1-2 Hits.
    Und das reicht nicht? Mal abgesehen davon, dass ein Bug auch dann ein Bug ist, wenn Du ihn vielleicht nicht siehst, sind Enforcer-Hits ja wohl schon Grund genug, um in einer anderen Umgebung, und AOS4 ist nunmal eine solche, überhaupt nicht mehr zu laufen.
    Zitat:
    >Du mißverstehst das Ziel von OS4. Es ist hauptsächlich ein PPC-OS.

    Ja, das könnte "OS3.9 for PPC" auch sein.
    Na, dann frag doch mal Haage&Partner, ob sie so etwas implementieren wollen.
    Zitat:
    >Die Grundidee beim Weiterentwickeln eines Betriebssystems ist, daß die meisten
    >Benutzer hauptsächlich die neue Version verwenden

    Und wozu? Damit sie sich 10 Minuten am Tag über ein paar wenige
    Programme freuen können die dafür geschrieben wurden?
    Oder die schönen bunten Fenster, die man doch wieder abschalten
    muss weil man zu wenig Speicher nutzten kann?
    Ja, genau dafür.
    Diese Problematik wurde doch schon oft durchdiskutiert, und jedem, der da ein Problem sah, stand es frei, AOS4 einfach nicht zu kaufen, solange es dieses Problem gibt. Wer es trotzdem kauft, sollte sich nicht beschweren.
    Zitat:
    Schonmal drüber nachgedacht das es diverse änderungen von OS2.0 zu OS3.9 gab und das da noch alles zu 99% läuft?
    Hust, röchel, Kaffee wieder wegwisch.
    Könntest Du mir bitte mal die Grundlage dieser Schätzung erläutern?
    Ich mein, hier handelt es sich um eine Änderung, die eher mit OS1.3 zu OS2.0 vergleichbar wäre. Trotzdem würde mich die Schätzung bzgl. OS2.0 zu OS 3.9 mal interessieren.
    Zitat:
    Also der JIT weiss Automatisch, welcher Teil der Interrupt ist und übergibt ihn an den herkömmlichen Emu. Alles andere wird in voller Geschwindigkeit ausgeführt?
    Andersherum wird ein Schuh daraus: eine konventionelle Emulation weiß von vornherein, ob sie ein Stück Code einem JIT übergeben kann, oder nicht. Und natürlich weiß das System, was ein Interrupt ist, und was nicht. Selbst, wenn eine Routine sowohl im Interrupt-Kontext, als auch in der normalem Anwendung verwendet wird, wäre das kein Problem: der 68k-Code wird ja vom JIT nicht gelöscht, kann somit auch vom Interpreter ausgeführt werden.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    26.11.2007, 17:16 Uhr

    [ - Direktlink - ]     		Thema: Software Interrupt Execution
    Brett: Amiga, AmigaOS 4

    @aming55:
    Software-Interrupts werden mit der Exec-Funktion Cause() ausgelöst, und die bekommt eine entsprechende Struktur mit Priorität übergeben. Und wenn mehrere solcher Interrupts (quasi) gleichzeitig ausgelöst werden, macht doch eine Festlegung einer Reihenfolge via Priorität Sinn, oder?

    Intern speichert die exec.library diese Strukturen natürlich irgendwo, und wenn schon *privat* an der entsprechenden Stelle steht, sollte man das auch respektieren, finde ich. Dann gibt's auch keine Verständnisprobleme.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
     
    Erste << 21 22 23 24 25 -26- 27 28 29 30 31 >> Letzte Ergebnisse der Suche: 2068 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.
    .