ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Amiga, AmigaOS 4 > "Virtueller RAM Speicher" als Partition oder in einer Datei | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
1 -2- 3 4 5 | [ - Beitrag schreiben - ] |
27.11.2007, 08:38 Uhr AMike Posts: 496 Nutzer |
@MaikG Sag mal was führst du denn hier auf? Du urteilst über OS4 als hättest du es bereits ausführlich getestet und schwingst dich hier als Instanz über Richtig oder Falsch in die Höhe. Wir leben in einem Käufermarkt, sprich, du kannst frei entscheiden was du kaufen willst. Wenn OS4 so viele Schwachpunkte hat, die du ja offensichtlich schon alle kennst, warum hast du es dann überhaupt bestellt? Scheint mir doch recht widersprüchlich, oder kann es sein das du lediglich Unruhe stiften willst? Ich persönlich bin jedenfalls froh wenn jemand mit einem tieferen Einblick in OS4 ausführliche und sachliche Informationen zur Verfügung stellt. [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 10:06 Uhr TetiSoft Posts: 197 Nutzer |
@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... Du mißverstehst das Ziel von OS4. Es ist hauptsächlich ein PPC-OS. Kein Startprogramm für alte Spiele. Es gibt bereits sehr gut funktionierende Startprogramme für alte Spiele (UAE und OS3) die der Benutzer normalerweise bereits besitzt. Die Grundidee beim Weiterentwickeln eines Betriebssystems ist, daß die meisten Benutzer hauptsächlich die neue Version verwenden auch wenn sie für manche alten Spiele oder Programme die alte Version starten müssen. Wenn die Vorgabe für OS4 gewesen wäre daß wirklich jede bisher existierende Software noch damit läuft, hätten die Programmierer erst gar nicht damit anfangen dürfen, weil jede Änderung an OS3 eine mögliche Inkompatibilität darstellt. > >Mit der Hardware-Abteilung und der Politik-Abteilung hab' ich > >nichts zu tun (zum Glück). > Hardware Abteilung? Meinst du Classic-Hardware tester? > Denn neue (inkompatible) Hardware gibt es nicht nur die > 2000 AOne User und das wars. Ich weiß nicht wen ich mit Hardware-Abteilung meine. Es ging um die neue Speicherverwaltung in OS4, ich hatte gesagt sie ist eher auf moderne Hardware ausgelegt, dann hattest Du gefragt wo denn diese moderne Hardware wäre. Welche Antwort erwartest Du von mir? Mehr als "Damit habe ich nichts zu tun"? > >Die neue Speicherverwaltung ist halt schon eher für moderne Hardware > >ausgelegt und kann mit langsamem Zusatzspeicher eben leider nichts mehr anfangen. > Siehe oben. > Die Speicherverwaltung war gut so wie sie war. War sie nicht. Auf der Hyperion-Seite ist irgendwo ein Artikel über die neue Speicherverwaltung. Sie sollte auf AOne, Arctic PDA, MacMini, klassischen Amigas und zukünftig unterstützter Hardware besser laufen als die alte, wenn man da Support für langsamen Zusatzspeicher reingebaut hätte den es nur auf klassischen Amigas gibt hätte man wegen wenig Nutzen alles verkompliziert und langsamer gemacht. > >Fehler passieren. > Du missverstehst mich, der ist bekannt und es war nicht geplant > das zu beseitigen. > Warte ab bis etwa zum 3.Dezember, dann komme ich sicherlich > mit 100erten von Programmen und 100erten Spielen die nicht > laufen. Nun, wenn der Fehler nicht genannt wird aber die Information daß er nicht beseitigt werden sollte kann ich natürlich nur spekulieren worum es eigentlich geht und hoffen daß es gute Gründe gab das Verhalten nicht zu ändern. Listen von nicht laufenden Programmen und Spielen sind hilfreich, sie ersparen anderen Benutzern das Ausprobieren und helfen evtl. bei der Fehlersuche. Vielleicht wird ja auch jemand Listen von laufenden Sachen erstellen. > >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ß. > Nein, wenn ich ein Programm schreibe muss ich legentlich > die CLI Zeile für den Compiler ändern und schon hab ich > ein PPC Programm. Das trifft dann zu, wenn der existierende Quellcode mit einem Compiler übersetzt werden kann. Es war vorher bekannt, daß große Teile des Kickstarts nur mit einem 68k-Assembler übersetzt werden können. Tatsächlich waren sogar einige Teile extra von C nach Assembler "rückportiert" worden um die letzten paar Bytes im 512K Kickstart-ROM einzusparen, und dann war nur noch der Assembler-Code weiterentwickelt worden. Als Beispiel mal Ausschnitte aus den releasenotes von graphics.library: ----snip---- graphics 46.25 (21.07.2002) <dwuerkner> - Changed compiler from Lattice C 5.10 to SAS/C. - Fixed d/find_key.c. Only a bug in Lattice C guaranteed to compile correct code from wrong source. - Fixed c/copper.c. The copstuff structure was declared two bytes smaller than in c/coppermover.asm so coppermover() did overwrite the stack variables of mrgcop(). - The pokecolors() function call in videocontrol.c did place the ViewPort argument on the stack. The function itself in a/NewColorStuff.a expected the argument in register A2. This did work only "by accident". - Fixed WriteChunkyPixels() which trashed A2 if chunky-to-planar hardware was present. - Added prototypes. - Fixed compiler warnings. - Compiled with "error=all". - Removed some useless stub code that only moved parameters from registers to the stack. - Replaced many internal function calls with standard calls using the library vector table. - Declared all data STATIC CONST which removed the data hunk (this is a ROM module) and compiled with "data=faronly". - Declared all custom chip registers VOLATILE to avoid that the optimizer optimizes too much. - Declared all static functions STATIC. - Declared all functions called from assembler code with parameters on stack as __stdargs. Where easy possible, used __asm instead for speed. - Compiled with "parameters=register" and with the optimizer on. - Replaced GBASE macro with a GfxBase parameter for all functions that needed it and compiled without "libcode" option to gain speed and size. - Removed (hopefully) all code that did read ExecBase from Chip RAM. - Replaced assembler version of OpenFont() with a C version that no longer treats font names case sensitive. - Replaced assembler version of WeighTAMatch() with a C version that is aware of TA_CharSet. - Replaced the assembler Region/RegionRectangle allocate/free functions with C versions. - The Region/RegionRectangle allocate/free functions now use Semaphore- protected AllocPooled() and FreePooled() instead of AllocMem() and FreeMem(). ... graphics 46.30 (29.08.2002) <dwuerkner> ... - Converted asm startup code to C. Converted lots of small asm functions to C. Where possible, removed stubs and STACKARGS. Reduced number of assembler source files from 92 to 21. ... - BugFix: SetRGB32CM() did set the lower nibble of the blue color from the wrong bits of the input longword, e.g. 0x01234567 -> 0x03. Fixed while converting to C. - After converting AreaDraw() to C, the WBClock did not display the hands with CyberGraphX4.2 (with Picasso96 or AGA no problem). Compiling without "optsched" option made the problem disappear. It seems CyberGraphX relies on the undocumented fact that AreaDraw() sets the zero flag depending on its d0 return value. Older colorwheel.gadget had the same problem. Added a compatibility hack return function to be able to use "optsched". ... - Fixed AskFont(), ClearEOL(), ClearScreen(), Text(), TextExtent(), TextFit() and TextLength() which generated enforcer hits if rp->Font was zero. - Fixed ExtendFont() to allocate enough memory (the undefined glyph was forgotten). Fixed ExtendFont() to no longer silently accept bad fonts. Fixed ExtendFont() to no longer show an AN_ObsoleteFont Alert() if AllocVec() failed. ... - Bugfix: GetRGB32() did ignore the LowColorBits on non-AGA machines. I published a patch for this bug in 1995... ... - BestModeID() no longer refuses to accept gfx board screen modes with a pixel speed < 35 nanoseconds. ... graphics 51.32 (1.10.2005) <dwuerkner> - Fixed a very old bug in TextFit() that was already present in the assembler version: When fitting right-to-left, a greater-or-equal comparison of the current width with the maximum width was used which resulted in the fact that the same string was not assumed to fit in the same width as when fitting left-to-right when the current width was equal to the maximum width. Changed it to a greater-only comparison which fixes the strange behaviour of the Prefs/Time year string gadget when placing the cursor at the end of the string and a proportional font was used as screen font (happened here e.g. with Tahoma/15) reported by Philippe Bourdin. ... graphics 51.36 (17.3.2006) <dwuerkner> - Changed some more variables in DrawEllipse() to 64bit to avoid an overflow with really large ellipses. Thanks to Stephan Rupprecht for the suggestion. ----snip---- > 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. Diese Argumentation wird oft benutzt. Sie setzt allerdings voraus, daß sowohl der OS3 Quellcode fehlerfrei war (was ich oben hoffentlich widerlegen konnte) als auch daß die existierenden 68k-Awendungen fehlerfrei waren. Ich versuche mal das auch zu widerlegen: ----snip---- kernel 51.10 (9.8.2004) ... - added a "tst.l d0" to OpenDevice() to keep Blitz programs working (actually those using the "nlibs"). ... intuition.library 50.29 (29.09.2003) ... - added temporary kludge to get DirOpus 4.16 working again (passes badly initialized NewWindow to OpenWindow). ... intuition.library 50.32 (21.11.2003) - Added a safety check for a NULL gadget pointer in ActivateGadget() to prevent Enforcer hits with reqtools.library screenmode requester ... intuition.library 51.14 (14.1.2005) <dwuerkner> - 68k hooks are now called with UtilityBase in register A6, in previous versions register A6 was undefined. This fixes WordWorth 7.01, its custom string gadget edit hook functions did cause a DSI in the emulator (input.device reading from NULL) with basepage-protected kernels which did effectively freeze the system (no wonder with a suspended input.device task). ... diskfont.library 50.53 (16.3.2004) <dwuerkner> - OpenDiskFont() now checks if the TextAttr parameter is NULL before using it. This fixes Enforcer hits with stricq that could occur when no fonts were specified in the stricq preferences. Thanks to Mario Cattaneo for his help to reproduce the bug. ... diskfont.library 51.12 (2.12.2006) <dwuerkner> - Added extra paranoia checks to protect against broken font files which have the FSF_TAGGED bit set but dfh_TagList is either NULL or points to the "moveq #n,d0" instruction at the start of the hunk. This fixes possible FixFonts crashes when the UniversHi bitmap font files are installed. Thanks to Ferrán García for the report and the font files. ... locale.library 47.21 (21.1.2003) <dwuerkner> - Added a compatibility hack for TurboCalc 3.50 which expects the result of GetCatalogStr() in register A0 after loading Catalogs/english/TurboCalcMenu.catalog. Thanks to Colin Wenzel for the bug report. ---snip---- > 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. Wir hatten schon vor Jahren ein lauffähiges OS4Classic, mußten aber trotzdem noch Änderungen daran vornehmen. Meiner Meinung nach ist es jetzt besser als vorher. Die Formulierung "ohne Grund drin rumgepfuscht" unterstellt den Programmierern Unvermögen. Ich bitte Dich darum, sie zurückzunehmen. > >Nicht nur angeblich, es gab schon einige Diskussionen weil die > >OS4 powerpc.library in Update#4 für den AOne noch dabei war aber > >seit OS4Final für den AOne nicht mehr dabei ist. > Und wo ist dafür der Grund? > Für einem OS Programmierer ist das ja kein Thema die > WOS Library Funktionen entsprechend umzupatchen damit es läuft. > (Siehe ppclibemu) Die Update#4 Version der powerpc.library funktioniert nur mit dem Update#4 Kernel richtig. Die Weiterentwicklung liegt auf Eis. In anderen Postings in diesem Thread wurde bereits erklärt daß es nur wenig Software gibt die man wirklich brauchen würde welche sich dadurch nicht benutzen läßt, der Aufwand würde sich also nicht richtig lohnen. > >Ich habe den JIT-Emulator hier normalerweise ausgeschaltet um mehr > >Speicher für gcc frei zu haben (Viele Komponenten von OS4 wurden auf > >meinem A4k compiliert). > Guck an 128 MB reichen jetzt wohl doch nicht mehr... Doch, ich konnte alles kompilieren was ich wollte. Es wäre auch mit JIT gegangen aber dann hätte ich ab und an ein paar Browser-Fenster schließen müssen. > Aber die Sache hat einen großen Hacken, nicht alles läuft mit > der JIT-Emu wie du sagtest. > Z.b. keine Interrupts?, also kein MovieShop, keine Toccata-Musikaufnahme, > Treiber uvm. Wenn ich das richig verstehe. > Ob genannte Software ohne JIT in aktzeptabler Geschwindigkeit > läuft ist fraglich, 68060 speed wirds auf keinen fall. Es ist interessant wie schnell man sich im Vorab ein Bild machen kann. Wenn man dann negative Prognosen veröffentlicht und dabei darauf achtet, daß man es so formuliert, daß man hinterher sagen kann man hätte ja nur Vermutungen angestellt, kann man noch nicht einmal richtig widerlegt werden wenn man falsch lag, aber wenn man richtig lag kann man sagen man wußte es vorher. In Interrupts wird für 68k-Code der JIT nicht verwendet weil er zu langsam wäre. Wenn der zweite Interrupt schneller abgearbeitet würde weil das Übersetzen nach PPC ja bereits im ersten passiert ist hilft einem das nichts weil der erste ja schon zu langsam abgearbeitet wurde, was bei Interrupts ja nicht passieren darf. Die Teile eines 68k-Programms die außerhalb eines Interrupts ausgeführt werden, was in der Regel der Hauptteil ist, werden normalerweise vom JIT ausgeführt. Auch 68k-Treiber wenn sie nicht zum Kickstart gehören oder sich z.B. in einem ROM auf einer Zorro-Karte befinden. In der Kompatibilitätsliste sind 68k-Treiber genannt die mit JIT nicht funktionieren und die der Benutzer mit einem Prefs-Programm in eine "schwarze Liste" eintragen kann damit sie trotzdem laufen. [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 10:40 Uhr MaikG Posts: 5172 Nutzer |
>Deswegen das ganze zu zerrden, bevor es überhaupt erschienen ist, mach aber auch keinen Sinn. Ja, stimmt, aber ein paar Limitationen geben uns schon Betatester/Entwickler und die sind schon erschreckend. Aber in der ersten Dezember Woche werde ich das natürlich konkretisieren und wenn ich jetzt ein falsches Bild habe dieses auch korregieren. >Wir wissen alle, dass du es mit der Wahrheit manchmal nicht ganz so genau nimmst - aber das geht ein bisschen zu weit. Das wissen nicht alle sondern nur legst du dir zurecht. Weil du ein PC-User bist, und trotzdem andere mich bestätigen bestehst du ja z.B. darauf das UAE so gigantisch schnell sei. Du hast doch überhaupt keinen Amiga - höchstens UAE. >OS4 ist noch nicht veröffentlicht, also hast du auch noch nicht dafür bezahlt. Ich habe per PayPal bei einem Seriösen Händler dafür bezahlt, wenn OS4 nicht kommt bekomme ich mein Geld zurück. >Du programierst nicht, oder? Doch, klar kein OS oder Riesenprogramm... >Ah, sinnvolle Erweiterungen und Fehlerbehebungen sind jetzt rumpfuschen, interressant. Es gab ja kaum Fehler. Ich rede z.B. vom verändern der Speicherverwaltung etc. >Der Grund ist das die ganzen WarpUp-only-Programme selbst mit funktionierender powerpc.library immer noch mehr als genug Bugs haben. Viele Software hat Bugs, OS4 Soft, 68k Soft - sollen ja auch laufen. Die WOS Bugs halten sich stark in grenzen, wenn dann gibts nal 1-2 Hits. >Glaubst du wirklich das Programmierer sich davon abhalten lassen ihrem Hobby nachzugehen, nur weil sie für Spiele OS3 booten müssen? Du missverstehst mich, einige (2 z.B. die ich persönlich kenne) und ich werden dann weiterhin ihren Hobby mit OS3.9 nachgehen. Und Fett in der Readme schreiben "Fragt nicht nach einer OS4 Version". >Du mißverstehst das Ziel von OS4. Es ist hauptsächlich ein PPC-OS. Ja, das könnte "OS3.9 for PPC" auch sein. >Kein Startprogramm für alte Spiele. Es gibt bereits sehr gut >funktionierende Startprogramme für alte Spiele (UAE und OS3) UAE will kaum ein richtiger Amiga-user jemand und ist auf Classic unbrauchbar. OS3 ist kein Startprogramm sondern ein OS(was wenn dann alleinig laufen sollte). >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? >Programmierer erst gar nicht damit anfangen dürfen, weil jede >Änderung an OS3 eine mögliche Inkompatibilität darstellt. Schonmal drüber nachgedacht das es diverse änderungen von OS2.0 zu OS3.9 gab und das da noch alles zu 99% läuft? >Das trifft dann zu, wenn der existierende Quellcode mit einem >Compiler übersetzt werden kann. Ja, ist mir klar das es beim OS, speziell bei den Initalisierungsroutinen anders laufen muss. >Die Teile eines 68k-Programms die außerhalb eines Interrupts ausgeführt >werden, was in der Regel der Hauptteil ist, werden normalerweise vom >JIT ausgeführt. 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? [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 11:34 Uhr Holger Posts: 8116 Nutzer |
Zitat: Das dachte ich bislang auch... Zitat:Wer auf dem Grund steht, kann nicht untergehen... Zitat: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 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:Wer nach allem, was geschehen ist, noch im voraus bezahlt, hat's nicht anders verdient. Zitat: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:Na, dann frag doch mal Haage&Partner, ob sie so etwas implementieren wollen. Zitat: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: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: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. [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 12:59 Uhr hacky Posts: 349 Nutzer |
@_PAB_ Ich finde gerade beim Händler meines Vertrauens etliche Kombo Netzwerkkarten mit dem 8029 "AS" Chipset und auch eine Terratec 128i Soundkarte. Ist 8029 = 8029AS bzw. kompatibel ? @ all: Noch ein Frage: "Terratec 128i PCI Prometheus/Mediator YES On Mediator A1200 still some problems" ist supported für den Mediator (A4000T) unter OS4. Bei Elbox wird diese Karte aber nicht in der Liste für OS3.9 geführt: Link Die Terratec hat den Chipsatz "ESS ES1938S Solo-1" soweit mir bekannt. Entspricht dies dem Chipset "EV1938 ,Vendor 1102, Product 8938" (eigentlich Creative Soundkarte(n) auf der Elbox Liste ? Oder anders gefragt hat jemand eine Terratec 128 i unter OS3.x am laufen ? -- A600, A1200 PPC240/060 Desktop, A4000 Tower PPC233/060, CD32, SX64, C64 und VC20 im Einsatz. [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 13:54 Uhr _PAB_ Posts: 3016 Nutzer |
@hacky: Ja, die 8029(AS) ist die richtige Karte, die von OS4 (auch ohne DMA) unterstützt wird. Die "Terratec 128i" hatte ich mal unter OS3.x laufen, allerdings mit einem GRex-4000D. Ich bin mir aber ziemlich sicher, daß auch diese Karte ohne DMA auskommt, denn sonst hätte sie bei mir nicht funktioniert. [ Dieser Beitrag wurde von _PAB_ am 27.11.2007 um 13:56 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 15:07 Uhr MaikG Posts: 5172 Nutzer |
>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, Ja, ich könnte meine Programme ändern falls es Probleme gibt. Aber keine Programme von anderen Programmierern, schon gar nicht ohne Sourcecode. Und dann ist die frage, warum soll ich mir die Arbeit machen, für ein OS was ich mangels kompatiblität so gut wie nie nutze. Und wenn ich mich dann doch für die Arbeit entscheide, wie kann ich es verantworten Software auf den Markt zu werfen welche ich bestenfalls Minutenlang unter OS4 getestet zu haben. >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? TLSF, ist nach meinen begrenzten Mathe wissen ja sehr Interessant. Aber da Enforcer damit nicht läuft benutze ich es (gar) nicht. Da auch eine schöne Analogie zu OS4. TLSF soll AllocMem beschleunigen und die Speicherfragmentierung reduzieren. Die Fragmentation tritt z.B. bei Programmen die "vergessen" ihren Speicher wieder freizugeben. Solange bei mir der Largest block über 100 MB liegt sehe ich kein Problem. Falls das doch mal vorkommen sollte mache ich einen Soft-Neustart das dauert unter 10 Sekunden. >besser wäre es definitiv nicht geworden, Das ist Ansichtssache, jeder setzt seine Prioritäten anders. Das Speichermanagement würde dann z.B. Fastlane+Motherboard Ram erlauben. >schließlich war OS3.9 schon Pfusch, und Gründe, >etwas zu ändern, gab es genug. Nur Minimale Bugs, gut ein schlimmer ist in RawbInfo und das war ja nun der externe Programmierer Stephan Rupprecht. Ins System selbst ist es nicht Integriert. Das man BB2-exec nicht benutzt werden sollte ist klar, man wird auch gewarnt. >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. Tja, so ein Hit könnte ich(oder andere) vielleicht entfehrnen, indem ich den Codebreich identifiziere und diesen umgehe oder fixe. Aber ohne powerpc.library erübrigt sich das. >Na, dann frag doch mal Haage&Partner, ob sie so etwas implementieren >wollen. H&P macht nichts mehr im Amiga-Bereich. >Ja, genau dafür. Und welche Soft soll das sein? Mozilla ist ja noch nicht portiert und soll auch sehr viel Speicher benötigen. >Diese Problematik wurde doch schon oft durchdiskutiert, und jedem, >der da ein Problem sah, stand es frei, AOS4 einfach nicht zu kaufen Normalerweise habe ich hier keine OS4 Threats gelesen, weil bis vor kurzem gab es das nur für AONE und war daher uninterressant. Ja, ich bin mir sicher der Verkauf wird deshalb schwach ausfallen. Es könnte auch sein das solche unzulänglichkeiten irgendwann durch Hyperion oder Fremdprogrammierer gelösst werden können. >Könntest Du mir bitte mal die Grundlage dieser Schätzung erläutern? Ja, ich habe mit OS2.0 angefangen, auch zu Programmieren. Ich musste bissher kein Programm welches noch von damals stammt austauschen. >Ich mein, hier handelt es sich um eine Änderung, die eher mit OS1.3 >zu OS2.0 vergleichbar wäre. OS1.3 hab ich nur mal kurz benutzt und nicht darauf Programmiert, mit der Aussage würde ich nur spekulieren. >Andersherum wird ein Schuh daraus: eine konventionelle Emulation >weiß von vornherein, ob sie ein Stück Code einem JIT übergeben kann, Weisst du das sicher oder ist es eine Annahme? Den wozu gibts dann eine Schwarze Liste wenn OS4 so clever ist? [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 15:14 Uhr TetiSoft Posts: 197 Nutzer |
@hacky:Zitat:Sie funktioniert mit AmigaOne und Prometheus. Mit Mediator ist der Sound "gestört". Wurde auf amigaworld.net oder amigans.net gesagt. Die Gründe sind noch nicht bekannt. Ich habe eine Prometheus hier und damit scheint sie gut zu laufen soweit ich es beurteilen kann, Sound ist nicht mein Interessensgebiet, ich bin also schon zufrieden wenn mit MultiView, den AHI Prefs und SoundPlayer Sound rauskommt, fürs Testen der Aufnahmefunktionalität oder Beurteilung der Qualität bin ich der falsche Tester :-) [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 15:26 Uhr hacky Posts: 349 Nutzer |
Zitat: Oh schade, ich dachte das bezieht sich nur auf den A1200 Mediator. Weil da steht: Prometheus/Mediator YES On Mediator A1200 still some problems Nun ja zu spät ich habe gerade eine Terratec 128i + eine Realtek mit 8029 Chip Netzwerkkarte gekauft. Ich bin allerdings auch nicht so ein Sound Fetischist. Die SoundBlaster 128 die hier seit einem Jahr im Mediator steckt habe ich bei meinen ersten zwei Versuchen unter OS39 nicht richtig installiert bekommen und es dann einfach gelassen. Da Paula + Audio CD meinen Ansprüchen genügte hat das auch nicht gestört. Es war nur so verlockend, da ich einen Händler gefunden hatte der noch eine Terratec 128i und auch eine 8029 Netzwerkkarte günstig verfügbar hatte. Da die Terratec 128i wohl auch unter OS39 funktioniert ist der "Verlust" zu verschmerzen. OS4 kann kommen... -- A600, A1200 PPC240/060 Desktop, A4000 Tower PPC233/060, CD32, SX64, C64 und VC20 im Einsatz. [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 16:46 Uhr ZeroG Posts: 1487 Nutzer |
@MaikGZitat:Solange du die alten und neuen Speicherfunktionen der Exec.library richtig benutzt (benutzt hast) und nicht probierst in Sachen direkt rumzupopeln von dennen schon seit OS1.x gesagt wurde das du da nichts zu suchen hast, dürftest du außer einem kräftigem Geschwindigkeitsschub nichts merken. Zitat:Wenn du dich an die Regeln gehalten hast, brauchst du nichts ändern. Obwohl es da ein paar Sachen gibt die du ändern solltest, um auch in Zukunft auf der sicheren Seite zu sein, aber das war bei jedem OS-Update so. Was willst du eigendlich merkwürdiges Testen in der Zeit in der du spielst und WHDLoad das Multitasking stoppt? Außer alten Spielen und Demos läuft das meiste doch unter OS4? Zitat:Du brauchst unter OS4 keinen Enforcer, das macht alles der Grimreaper und der läuft perfekt mit dem neuen Speichersystem. Zitat:Du solltest dich nochmal Informieren was Fragmentation eigendlich ist, es hat nichts mit nicht wieder freigegebenen Speicher zu tun. Zitat:Für den du erstmal alles was gerade offen ist speichern mußt. Womit es länger als 10s braucht, wenn dich die Programme überhaupt noch speichern lassen. Den Speicher den sie haben wollten haben sie ja an diesem Punkt schon nicht bekommen, hoffendlich ist die Fehlerbehandlung der Programme verdammt gut. Zitat:Und dafür die A1 und alle zukünftigen Plattformen langsamer und unstabiler machen? Nein danke. Die Idee den Mobo+Fastlane-Speicher als schnelleren Auslagerungsspeicher anstatt der Festplatte zu benutzten klingt für mich ganz gut, braucht halt noch etwas Zeit, was solls... Zitat:Komisch, soweit ich mich erinnern kann kamen diese Sachen fast alle erst nach dem Release raus. Zitat:Dann fang doch schon mal an. Wenn du fertig bist melde dich beim OS4-Team und entkräfte die Argumente die gegen eine neue powerpc.library sprechen. Und vergess nicht gleich noch den Warp3D Teil der alten Spiele zu verbessern, der macht nämlich auf allem was neuer als ne Voodoo ist auch Probleme, weil damals auf nichts anderem getestet werden konnte. Zitat:Guck doch mal ins Aminet oder ins Os4Depot, da findet sich einiges. Und die alten 68k-Programme profitieren meistens auf die eine oder andere Art vom neuen System und laufen schneller. Zitat:Besonders clever war das aber nicht. Wenn schon interresse an OS4 besteht sollte man auch mal bei denen vorbeigucken die es schon längere Zeit in benutzung haben. Zitat:Du hast ja auch noch nie den 68k durch einen PPC ersetzt... Was ist mit den ganzen Programmen die nicht mit AGA oder den Caches der neueren CPUs klar gekommen sind? Das kannst du mir so nicht erzählen. Zitat:Eigendlich spekulierst du in diesem Thread in einem durch. Gekauft hast du schon, also gucks dir erstmal an und beschwer dich dann über Sachen die dir nicht in den Kram passen. Am besten sachlich ohne vermutungen und mit ein paar guten Argumenten, sowas wirkt manchmal Wunder. Zitat:Lese doch mal richtig. Interruptcode wird nicht vom JIT ausgeführt, da man Interrupt-code bei exec in Listen eintragen muß wird der 100%ig erkannt. Alles andere wird vom JIT (wenn er eingeschaltet ist) übersetzt, außer den Sachen die in der Blacklist stehen. [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 18:09 Uhr MaikG Posts: 5172 Nutzer |
>Was willst du eigendlich merkwürdiges Testen in der Zeit in der du >spielst und WHDLoad das Multitasking stoppt? Ich nehme das OS wo am meisten Soft+Spiele drauf läuft und das wird wohl 3.9 sein. >Außer alten Spielen und Demos läuft das meiste doch unter OS4? Muss man sehen wenns da ist. Das mit WHDLoad ist aber auch sehr schlimm, ich habe bestimmt 100 Spiele damit. >Du solltest dich nochmal Informieren was Fragmentation eigendlich ist, >es hat nichts mit nicht wieder freigegebenen Speicher zu tun. War nur ein bespiel, ich weiss was Fragmentation ist. >Für den du erstmal alles was gerade offen ist speichern mußt. Das kommt vielleicht 3 mal im Jahr vor. >Und dafür die A1 und alle zukünftigen Plattformen langsamer und >unstabiler machen? Nein danke. Weisst du doch gar nicht. Ausserdem würde ich lieber auf den jetzigen größten User-Kreis rücksicht nehmen, statt auf etwas was vielleicht niemals kommt. >Dann fang doch schon mal an. >Wenn du fertig bist melde dich beim OS4-Team und entkräfte die Argumente >die gegen eine neue powerpc.library sprechen. Das ist mir zu unsicher. Ich glaube nich das dies der grund war die powerpc.library rauszunehmen. Solange kein WOS programm die öffnet gibt es ja keine beeinträchtigung. Notfalls würde diese halt nicht mitinstalliert und man müsse das manuell machen. >Und vergess nicht gleich noch den Warp3D Teil der alten Spiele zu >verbessern, der macht nämlich auf allem was neuer als ne Voodoo ist >auch Probleme, weil damals auf nichts anderem getestet werden konnte. Du vergleichts Äpel mit Birnen. Einen Hit zu entfehrnen ist eine Sache, an W3D rumbasteln eine wesentlich schwierigere. >Guck doch mal ins Aminet oder ins Os4Depot, da findet sich einiges. Ins Aminet(neuste Software) gucke ich immer wieder, nur was so besonderes hab ich da nicht gesehen. >Besonders clever war das aber nicht. Mag sein, aber das auf dem AONE fast nix läuft war ja klar da die Hardware nicht da ist. >Was ist mit den ganzen Programmen die nicht mit AGA oder den Caches >der neueren CPUs klar gekommen sind? Schonwieder Äpfel<->Birnen. Wir reden vom OS, nicht von der HW. Ausserdem waren das die Kandidaten welche sich nicht an die Richtlinien hielten. UND: Davon liefen dann immernoch 98% mit Bootmenu/Degraden. Für die übrigen 2% gibts WHDLoad. Ich kann dir sagen, die Spiele, welche ich mir in der Anfangszeit kopiert/gekauft habe laufen heute alle zu 100%. >Gekauft hast du schon, also gucks dir erstmal an und beschwer dich dann über Sachen die dir nicht in den Kram passen. Okay. >Alles andere wird vom JIT (wenn er eingeschaltet ist) übersetzt, außer den Sachen die in der Blacklist stehen. Aha, und warum muss man etwas in die Blacklist eintragen? Ich meine in WINUAE läuft auch alles per JIT was ohne läuft? [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 19:05 Uhr Lemmink Posts: 2344 Nutzer |
Zitat: ACHTUNG !! ACHTUNG !! Du legst gesteigerten Wert auf Software die nicht Customchip unabhängig ist ? Für dich ist WHDLoad eine der Hauptanwendungen auf dem Amiga ? Dann lass die Finger von OS4, es ist absolut nichts für dich, du gehörst nicht zur Zielgruppe von OS4. Halte mindestens 5 Meter Sicherheitsabstand. Warne andere Betroffenen denen es ähnlich geht !! ACHTUN !! ACHTUNG !! -- Das Grauen hat viele Gesichter und mein Spiegel zeigt mir jeden Morgen ein neues. Jetzt neuer, aber immer noch nicht interessanter: http://www.lemmink.joice.net [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 22:07 Uhr TetiSoft Posts: 197 Nutzer |
@MaikG: > Aha, und warum muss man etwas in die Blacklist eintragen? > Ich meine in WINUAE läuft auch alles per JIT was ohne läuft? Mit WINUAE kenne ich mich nicht aus. Prinzipbedingt kann ein JIT-Emulator nicht so kompatibel sein wie ein interpretierender Emulator. Was mir an Gründen so einfällt: - Zeitkritische Routinen laufen im JIT später los, dann laufen sie aber schneller. Mit Interrupts kann das Probleme geben (hatten wir schon, dafür wird JIT eh nicht verwendet), aber auch mit Code der direkt auf langsame Hardware-Register zugreift ohne "richtig" (z.B. per timer.device) auf die Hardware zu warten, wenn der JIT dann eine Warteschleife zu schnell abarbeitet und die Hardware noch nicht bereit oder fertig ist kann es Probleme geben. Mögliche Kandidaten für sowas sind 68k-Hardware-Treiber die nicht konservativ sondern eher mit Blick auf Benchmark-Werte programmiert wurden. Ich vermute mal daß unter UAE der Treiber nicht laufen würde weil die Hardware nicht emuliert wird oder daß er läuft weil die Hardware ja nur emuliert ist und das genaue Timing nicht so wichtig ist. - Selbstmodifizierender Code unter JIT modifiziert nur das 68k-Original aber nicht die übersetzte Kopie die schon läuft und arbeitet deshalb nicht so wie sich der Programmierer das eigentlich gedacht hat. Leider (oder besser zum Glück) kenne ich kein Beispiel für so ein (gegen die Richtlinien verstoßendes) Programm. - Ein "halber" Grund ist daß ein JIT komplizierter ist und deswegen auch mehr unentdeckte Fehler drinstecken können. Bei WINUAE sind viele sicher bereits gefunden worden. - Bei WINUAE wird höchstwahrscheinlich (zu Recht) davon ausgegangen daß ein Programm immer in 68k-Code reinspringt. Der OS4 JIT muß aber wissen ob ein Sprungziel 68K oder JIT oder PPC Code ist. Dazu merkt sich OS4 die 68k Segmente welche mit LoadSeg() geladen werden und mit UnLoadSeg() wieder freigegeben werden. Wenn ein 68k-Programm seine eigene Segmentliste verändert kann das Probleme mit dem JIT geben. Beispiele dafür sind alte Versionen von IPrefs, RexxMast, SetPatch sowie selbstentpackende Programme die mit z.B. PowerPacker gepackt wurden. Die BlackList die mit OS4 mitgeliefert wird enthält drei Einträge für alte Programme (die Einträge sind mit Prüfsumme und gelten daher immer für eine ganz bestimmte Version) die einfach sicherheitshalber dringelassen wurden sowie einen Eintrag für eine AmiTradeCenter-Version. In der Blacklist sind außerdem auch Programme drin die nicht mit dem JIT aber mit der dos.library Probleme verursachen, mit dem gleichen Prefs-Editor kann man da die DOS-Warnrequester für solche Programme abstellen. Und damit ist das erste Problem der Installations-CD entdeckt, die in der Kompitibilitätsliste als "has to be blacklisted" erwähnten Programme hätten wir ja auch schon eintragen können. Sorry. [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 23:41 Uhr MaikG Posts: 5172 Nutzer |
>Du legst gesteigerten Wert auf Software die nicht Customchip unabhängig >ist ? Wenn mir einer etwas gleichwertiges, unabhängig von den CC programmiert wäre das auch gut. >Für dich ist WHDLoad eine der Hauptanwendungen auf dem Amiga ? Nein, aber auch etwas was ich vielleicht selten benutze kann auserordentlich wichig sein. >aber >auch mit Code der direkt auf langsame Hardware-Register zugreift >ohne "richtig" (z.B. per timer.device) auf die Hardware zu >warten, wenn der JIT dann eine Warteschleife zu schnell abarbeitet >und die Hardware noch nicht bereit oder fertig ist kann es Probleme >geben. Könnte vielleicht ein Problem sein. Per timer.device Timen währe eh zu lahm für die meisten Sachen(siehe meine Threats in Programmieren). Daher nutzt man z.B. für den Serial/Parallel etc. Transfer Interrupts. >- Selbstmodifizierender Code unter JIT modifiziert nur das >68k-Original aber nicht die übersetzte Kopie die schon läuft Ja, aber einige Programme die sich selbst modifizieren stürzen eh schon mit Cache ab. IDEFix dürfte ein Kandidat dafür sein, soweit ich weiss schreibt es in sich selbst, weshalb man die Extres Buffer damit zusammen nicht schreibschützen kann. >- Ein "halber" Grund ist daß ein JIT komplizierter ist und deswegen >auch mehr unentdeckte Fehler drinstecken können. Bei WINUAE sind >viele sicher bereits gefunden worden. Auch wenn WinUAE nicht mein ding ist aber der hat auch mehr als 2000 AONE User + Classic Beta tester zusammen. >sowie selbstentpackende Programme die mit z.B. PowerPacker gepackt wurden. Jetzt hast du schon ca. 40 Spiele gekillt die ohne WHD laufen. >In der Blacklist sind außerdem auch Programme drin die nicht mit >dem JIT aber mit der dos.library Probleme verursachen, mit dem >gleichen Prefs-Editor kann man da die DOS-Warnrequester für solche Programme abstellen. Kann ich auch verhindern das die bunten Fenster bei speziellen Programmen verwendet werden? Einige Programme gehen z.B. davon aus das der Linke(u. ggf. Rechte) Fensterrahmen genau 4 Pixel breit ist. [ - Antworten - Zitieren - Direktlink - ] |
27.11.2007, 23:51 Uhr ZeroG Posts: 1487 Nutzer |
@MaikGZitat:Was weiß ich nicht? Ich hab den Geschwindigkeitsunterschied auf dem A1 mitbekommen als das neue Speichersystem kam. Neue Hardware (wenn sie den irgendwann kommt) wird nur eine Art Speicher haben, das kann man ja wohl als gegeben ansehen, oder? Zitat:Naja, von gefixten Hits haben auch die OS3.x-ler was, nämlich stabilere Spiele, und falls wie bei Wipeout noch debugcode drin ist der ins Chipram schreibt, wird es sogar minimal schneller. Wäre also schon mal nicht umsonst. Zitat:Stimmt schon irgendwo, ist aber auch ein gutes Beispiel dafür das die Spiele auch ohne Hits noch genug Probleme haben. Zitat:Was suchst du denn? Zitat:Stimmt so nicht ganz, die alten Spiele laufen nur mit E-UAE aber an Anwendungen vermiss ich nichts. Wenn du natürlich hauptsächlich spielen willst... Zitat:Das der 68k durch einen PPC ersetzt wird, ist keine neue Hardware? [ - Antworten - Zitieren - Direktlink - ] |
28.11.2007, 00:01 Uhr ZeroG Posts: 1487 Nutzer |
Zitat: Für einzelne Programme - Nein. Systemweit für alle Programme - Ja, mit Prefs/GUI. Default sind 5 Pixel, dürfte also kaum auffallen wenn man das auf 4 Pixel runterschraubt. Obwohl mir (mal wieder) bis jetzt keine Programm untergekommen ist für das das notwendig ist. [ - Antworten - Zitieren - Direktlink - ] |
28.11.2007, 01:54 Uhr cgutjahr Posts: 2783 [Administrator] |
Zitat:Sämtliche GUI-Settings lassen sich für jeden Bildschirm einzeln definieren. Das ist zwar nicht "pro Programm", aber nahe genug dran. -- Gutjahrs Amiga Seiten [ - Antworten - Zitieren - Direktlink - ] |
28.11.2007, 07:22 Uhr TetiSoft Posts: 197 Nutzer |
@MaikG: > >aber > >auch mit Code der direkt auf langsame Hardware-Register zugreift > >ohne "richtig" (z.B. per timer.device) auf die Hardware zu > >warten, wenn der JIT dann eine Warteschleife zu schnell abarbeitet > >und die Hardware noch nicht bereit oder fertig ist kann es Probleme > >geben. > Könnte vielleicht ein Problem sein. > Per timer.device Timen währe eh zu lahm für die meisten Sachen(siehe meine Threats in Programmieren). > Daher nutzt man z.B. für den Serial/Parallel etc. Transfer > Interrupts. Ich dachte eher an Hardware wo man z.B. nach Setzen eines Bits soundsoviel Mikro- oder Nanosekunden warten muß bis man ein anderes Register lesen oder schreiben kann. Für den Mikrosekundenbereich gibts in OS4 eine neue Funktion die natürlich von alten Programmen nicht verwendet wird. 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). > >sowie selbstentpackende Programme die mit z.B. PowerPacker gepackt wurden. > Jetzt hast du schon ca. 40 Spiele gekillt die ohne WHD laufen. Nicht gekillt, nur gefunden. Man kann sie von Hand entpacken oder in die Blacklist eintragen. [ - Antworten - Zitieren - Direktlink - ] |
28.11.2007, 10:36 Uhr MaikG Posts: 5172 Nutzer |
>Ich hab den Geschwindigkeitsunterschied auf dem A1 mitbekommen als >das neue Speichersystem kam. War das alte identisch mit dem von OS3.9? Denn die hatten ja die src nicht. Bei OS4 gibts oft mehrere Updates, war es genau das? Oder war es nur ein Bug der irgendwo reingeraten ist? >Neue Hardware (wenn sie den irgendwann kommt) wird nur eine Art >Speicher haben, das kann man ja wohl als gegeben ansehen, oder? Stecke ich einen Shark in den A4000 habe ich Motherboard Ram, Turbokarten ram und Shark ram. Klar braucht man da nur den Shark Ram weil man da vermutlich ohne weiteres 1 GB reinstecken kann. >Naja, von gefixten Hits haben auch die OS3.x-ler was, nämlich >stabilere Spiele, und falls wie bei Wipeout noch debugcode >drin ist der ins Chipram schreibt, wird es sogar minimal schneller. >Wäre also schon mal nicht umsonst. Wipeout hab ich nicht. Bei Napalm habe ich drüber nachgedacht, weil ich hab "LED" an in Cyberquard und es kommen genau soviele hits das der Sound-Filter an bleibt. >Was suchst du denn? Ich guck nur immer was neu hochgeladen wurde. Was ich für OS3.9 noch gerne hätte? Einen DVD/Videoplayer ohne Bugs, mh spontan fällt mir gar nichts weiter ein. >Stimmt so nicht ganz, die alten Spiele laufen nur mit E-UAE aber an >Anwendungen vermiss ich nichts. Ja, aber genau genommen könnte ich dann gleich OS3.9 auf Win-UAE laufen lassen und müsste es damit nicht bei jedem Spiel starten. >Das der 68k durch einen PPC ersetzt wird, ist keine neue Hardware? Der 68k wird doch durch die Emu's ersetzt und der PPC war vorher schon da. >Default sind 5 Pixel, dürfte also kaum auffallen wenn man das auf >4 Pixel runterschraubt. Ich sehe das wenn die schwarze Linie fehlt weil ich diese überzeichnet habe. Das sind auch u.a. Programme die kein eigenen Screen öffnen. >Obwohl mir (mal wieder) bis jetzt keine Programm untergekommen ist >für das das notwendig ist. Ja, ihr Betatester scheint sehr wenig Software, Spiele und Hardware zu haben... Ein blick auf die Blacklist von diesen GUI-Replacements für 3.9 wäre sinnvoll gewesen. Scalos nennt sich eines davon. [ - Antworten - Zitieren - Direktlink - ] |
28.11.2007, 15:04 Uhr ZeroG Posts: 1487 Nutzer |
@MaikGZitat:Genau wirds nur H&P wissen, aber ich glaub nicht das zwischen 3.1 und 3.9 am Speichersystem gedreht wurde. War soweit ich weiß also 3.1 bloß in PPC-Code. Zitat:Ich kann dir nur den unterschied zwischen dem letzten öffendlichen Update vor dem neuen Speichersystem und dennen die danach kammen bestehtigen. Wenn das mit dem Geschwindigkeitsunterschied nicht schon vom Prinzip her stimmen würde, hatten hier schon die richtigen Leute Mord und Brand geschriehen. Wenn du das Changelog zu Exec sehen willst mußt du mal einen Entwickler fragen, z.B. TetiSoft. Zitat:Glaubst du wirklich das Shark erscheint noch? Durch RoHS müssen die das komplette Design überarbeiten und seit das mal geplant wurde ist die zahl der potenziellen Käufer kräftig gesunken. Da kommt ,wenn überhaupt, SAM oder irgendwas in die Richtung. Man kann ja nicht ewig alles in einen A1200/A4000 stopfen, da muß irgendwann mal Schluß sein um voran zu kommen. Hält ja auch nicht ewig so ein Classic. Zitat:Ich meinte eigendlich für OS4... Und da wirst du mit DvPlayer und MPlayer fündig. Auf der Musikseite ist TuneNet prima. Zitat:Der PPC wahr vorher nur ein Co-Prozessor. Sowas ist eine große Änderung. Zitat:hä? Wenn DU über diese Linie zeichnest, hast du einen Bug in deinem Code den du beheben solltest. Falls du damit jetzt Programme meinst die das machen und die du nicht geschrieben hast, hab ich dir doch gerade gesagt das du die Rahmenstärken frei einstellen kannst -> kein Problem -> keine GUI-Blacklist nötig. Zitat:Ich bin kein Betatester, nur ein otto-normal A1 und bald OS4Classic-User. Aus der Perspektive von dennen die noch kein OS4 haben sind natürlich alle mit einem A1 Betatester. Da ist schon was dran. Fakt ist, es hat sich kein einziger A1-User in allen 4 Amigaforen die ich regelmäßig lese über irgendwelche Probleme mit diesen Rändern beschwert. Haben dir alle A1-User+Betatester+Kernentwickler wirklich nicht genug Software zum Testen? Zitat:Man kann es mit diesen Blacklists auch übertreiben. Was nicht vernünftig funktioniert fliegt halt raus, sobalt brauchbarer Ersatz da ist. Ende vom Lied. Ich mag den Classic aber man kann die ganzen Altlasten doch nicht ewig mitschleppen. [ - Antworten - Zitieren - Direktlink - ] |
28.11.2007, 18:06 Uhr MaikG Posts: 5172 Nutzer |
>Da kommt ,wenn überhaupt, SAM oder irgendwas in die Richtung. Sam ist doch keine Classic Turbokarte oder? >Man kann ja nicht ewig alles in einen A1200/A4000 stopfen, >da muß irgendwann mal Schluß sein um voran zu kommen. Deine meinung, sicher auch die der AONE-only user. Nur nicht meine, entweder kommen kompatible neue Amigas oder ich benutze die alte Hardware weiter. Und wenn das für den rest meines Lebens sein sollte. >Ich meinte eigendlich für OS4... Ja, ich kombinierte das jetzt mit der frage welche Soft die es auf 3.9 nicht gibt und wofür man evtl. OS4 nehmen würde. >Auf der Musikseite ist TuneNet prima. Ach, mit Amplifier bin ich vollauf zufrieden. >Der PPC wahr vorher nur ein Co-Prozessor. Sowas ist eine große Änderung. Das ist Relativ zu sehen. Du kannst mit einem PPC auch alles machen was ein 68060 kann. Um bestimmte Intructions zu ersetzen kann es natürlich sein das du 2 oder 3 Befehle benutzen musst. Ähnlich macht es die 68040/060 Library mit befehlen die diese CPU's nicht mehr können. >Wenn DU über diese Linie zeichnest, hast du einen Bug in deinem Code >den du beheben solltest. Sag mir kurz wie ich feststelle wie groß der Linke rahmen ist. >hab ich dir doch gerade gesagt das du die >Rahmenstärken frei einstellen kannst -> kein Problem -> >keine GUI-Blacklist nötig. Cool. >Was nicht vernünftig funktioniert fliegt halt raus, sobalt brauchbarer Ersatz da ist. Ja, da ist das wieder das bereits angesprochene Problem. Keine Sources, direktes nachmachen ist nicht legal(Copyright), nicht genug Programmierer und einige Programmierer wollen vielleicht nicht für OS4 Programmieren. [ - Antworten - Zitieren - Direktlink - ] |
28.11.2007, 19:44 Uhr ZeroG Posts: 1487 Nutzer |
@MaikGZitat: Spontan könnte man sich einfach mal die "struct Window" definition in intuition/intuition.h ansehen, ist seit Eoenen da drin. code:/* the border variables describe the window border. If you specify * WFLG_GIMMEZEROZERO when you open the window, then the upper-left of * the ClipRect for this window will be upper-left of the BitMap (with * correct offsets when in SuperBitMap mode; you MUST select * WFLG_GIMMEZEROZERO when using SuperBitMap). If you don't specify * ZeroZero, then you save memory (no allocation of RastPort, Layer, * ClipRect and associated Bitmaps), but you also must offset all your * writes by BorderTop, BorderLeft and do your own mini-clipping to * prevent writing over the system gadgets */ BYTE BorderLeft, BorderTop, BorderRight, BorderBottom; Zitat:Muß ja nicht unbedingt ein Port sein, sondern was neues mit vergleichbarer Funktion. [ - Antworten - Zitieren - Direktlink - ] |
28.11.2007, 21:21 Uhr Holger Posts: 8116 Nutzer |
Zitat: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. [ - Antworten - Zitieren - Direktlink - ] |
28.11.2007, 21:30 Uhr Holger Posts: 8116 Nutzer |
Zitat: Ä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. [ - Antworten - Zitieren - Direktlink - ] |
28.11.2007, 22:27 Uhr ZeroG Posts: 1487 Nutzer |
@HolgerZitat:Äonen, richtig. Zitat: Na, wollen wir da etwa Unschuldige in versuchung führen? Am besten immer nur den "richtigsten" Weg aufmalen, so kommt das gar nicht erst zu merkwürdigen Ideen. [ - Antworten - Zitieren - Direktlink - ] |
29.11.2007, 10:26 Uhr MaikG Posts: 5172 Nutzer |
> BorderLeft and do your own mini-clipping to Okay, probiere ich mal. Naja, ich meine es waren ja immer 4 Pixel, da Programmiert man halt so effektiv wie möglich und benutzt sowenig wie möglich berechnungen. >Muß ja nicht unbedingt ein Port sein, sondern was neues mit >vergleichbarer Funktion. Trotzdem um alle bestehende Soft abzudecken brauchst du sehr sehr viele Programmierer. Bei Spielen ist eine ähnliche Funktion schwer. Guck die AmHuhn an, das macht nicht soviel Fun wie Moorhuhn. >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. 2 Spiele hab ich hier die Timen gar nicht... Auf >68000 sind die sehr schnell, kann man in 3.9 aber degraden. [ - Antworten - Zitieren - Direktlink - ] |
29.11.2007, 10:44 Uhr ZeroG Posts: 1487 Nutzer |
@MaikG:Zitat:Das ist genau die miese Einstellung weshalb unter Scalos & Co GUI-Blacklists überhaupt erst nötig sind. Ganz zu schweigen von den ganzen Kompatibilitätshacks die durch sowas nötig werden, weil es sonst heißt das System ist schuld, obwohls an den benutzten Programmen liegt. Sich nicht an die RKMs und Autodocs zu halten ist nicht effektiv sondern dämlich. [ - Antworten - Zitieren - Direktlink - ] |
29.11.2007, 10:46 Uhr tboeckel Posts: 124 Nutzer |
@MaikG:Zitat: Genau da liegt das Grundproblem des Amiga. Mit Effizient hat das wenig zu tun. Wenn das Auslesen der Rahmengröße aus einer Struktur im Gegensatz zu einer Konstante wirklich Performanceprobleme verursacht, dann hat so ein Programm noch ganz andere Probleme. Nur weil viele Sachen "schon immer so waren" heißt das noch lange nicht, daß sie "auch immer so bleiben". Die Rahmengröße in der Fensterstruktur existiert schon seit OS1.x, nur stehen viele Programmierer auf dem Standpunkt, daß man solche Sachen nicht benutzen braucht, wenn man es selbst besser weiß als das OS. So was muß früher oder später dazu führen, daß man sich selbst (und auch anderen) in den Fuß schießt. Als das neue Speichersystem in OS4 implementiert wurde gab es ähnliche Diskussionen, weil einige Programme die undokumentierte Tatsache ausgenutzt haben, daß AllocVec() die Speichergröße an einer bestimmten Stelle speichert. Als das dann unter OS4 nicht mehr funktionierte, weil diese Größenangabe vom OS plötzlich gar nicht mehr benötigt wurde, da war das Geschrei groß. Aber komischerweise konnte niemand außer "Bequemlichkeit" wirklich gute Gründe angeben, warum man schlauer als das OS sein sollte und darum undokumentierte Zufälle ausnutzen darf. Das hat nichts mehr mit Kompatibilität zu tun. 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! [ - Antworten - Zitieren - Direktlink - ] |
29.11.2007, 11:15 Uhr Holger Posts: 8116 Nutzer |
Zitat: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. [ - Antworten - Zitieren - Direktlink - ] |
29.11.2007, 11:40 Uhr MaikG Posts: 5172 Nutzer |
>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. Richtig, hab ebend nachgesehen, die Linke Fensterleiste wird bei den MB Beispielen(welche übersetzungen aus den C-Examples sind) nicht verwendet. [ - Antworten - Zitieren - Direktlink - ] |
1 -2- 3 4 5 | [ - Beitrag schreiben - ] |
amiga-news.de Forum > Amiga, AmigaOS 4 > "Virtueller RAM Speicher" als Partition oder in einer Datei | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |