Zitat:

---

Original von schluckebier:

Zitat:

---

Original von whose:
Linux ist in diesem Bereich alles andere als flexibel, das steht nun mal fest. Entweder die Hardware paßt sich dem OS an, oder DMA geht nicht. Das ist wohl mehr Grund für Satire als der Fehler des Articia.

---

Tut mir leid, das was du da schreibst, das IST Satire. Dass Linux davon ausgeht, dass Cache-Kohärenz gegeben ist, das ist NORMAL. Auch Mai fand das mal normal, allerdings haben die die Specs mal eben geändert, als sie gemerkt haben, dass der Articia in dieser Hinsicht eben defekt ist. Offiziell kann das Ding nämlich mittlerweile gar kein DMA mehr. :o)

---

Zitat:

---

Zitat:

---

Unter AmigaOS geht DMA problemlos, darum ging es hauptsächlich.

---

Du führst also ein Betriebssystem, das für dieses spezielle Verhalten (um mal das schlimme Wort "Fehler" zu vermeiden) Workarounds hat, als Gegenbeweis an? Interessante Argumentation. ;o)

Meine Klospülung ist nicht kaputt, du bist als Benutzer höchstens nicht daran angepasst, wenn du keinen Eimer Wasser mitnimmst. :o)

---

Ob das ein "Workaround" ist, steht auf einem ganz anderen Blatt. Frag doch mal Stephane Guillard, ob er das genauso sieht. In einem Thread auf AW sagte er dazu nämlich sinngemäß, daß er den Treiber auf die Art "natürlicher" schreiben konnte, soll bedeuten, daß die Zuständigkeit für die Cache coherency seiner Ansicht nach nun an der Stelle liegt, wo sie eigentlich hingehört.

Ist schon interessant, wie Altlasten einfach zum Standard erklärt werden. Wie bei Microsoft

Übrigens, es gibt Linux-Distributionen (hauptsächlich für small scale Anwendungen, wie z.B. Mobile Linux), die das gleiche Kunststück wie AmigaOS beherrschen. DMA ohne Hardware-Cache-Kohärenz

Grüße


Edit: MAI läßt sich gar nicht mehr zum Thema IDE und Articia aus, wie ich gerade gesehen habe. Linux scheint übrigens auch kein Thema mehr zu sein. Ob das daran liegt, daß der Articia nicht so arbeitet, wie vorgesehen oder obs daran liegt, das die MAI-Ingenieure da einfach gepennt haben und das Feature nicht für wichtig angesehen haben (weil merkwürdigerweise nur Linux/Unix von dem Problem betroffen ist), bleibt Spekulation.

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 25.07.2005 um 13:24 Uhr editiert. ]

Zitat:

---

Original von Zettmaster:
@whose:

Beschreibe mal genau den Weg zu der Tastatur einstellungen im U-Boot.
Ich habe die neueste Version. Leider bin ich zu doof die Einstellungen für eine USB Tastatur zu finden...

---

Nee, ich bin zu doof Das wird über eine UBoot-Env-Variable festgelegt. Da muß ich selbst erstmal blättern...

Zitat:

---

PS: Ich finde den AOne gar nicht mal schlecht,bis Dato sind das ja alles nur Config Fehler meinerseits. Ich denke mal in 1 Woche kann ich gut mit arbeiten...Wenn es OS4 auch fürn Peg geben würde gäbe es so manche Auseinandersetzung hier nicht...Friede

---

Amen.

Grüße

P.S.: Ich habs jetzt auf die Schnelle nicht definitiv herausgefunden, aber es scheint die Variable "stdin" zu sein (die steht standardmäßig auf "ps2kbd").
Ich würde an Deiner Stelle aber nochmal bei intuitionbase.com und auf AmigaWorld nachlesen, ob das stimmt. Da müßte einiges zu dem Thema zu finden sein. Nicht daß Du nachher gar nicht mehr ins UBoot-Menü kommst

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 25.07.2005 um 13:05 Uhr editiert. ]

Zitat:

---

Original von schluckebier:

Zitat:

---

Original von whose:
DMA ist kein Problem unter AmigaOS. Das Linux für den sich darauf verläßt, daß die Hardware sich um den Cache kümmert, ist das Problem von Linux.

---

Bitte sag, dass das Satire ist. Bitte.

---

Warum sollte ich? Linux ist in diesem Bereich alles andere als flexibel, das steht nun mal fest. Entweder die Hardware paßt sich dem OS an, oder DMA geht nicht. Das ist wohl mehr Grund für Satire als der Fehler des Articia.

Unter AmigaOS geht DMA problemlos, darum ging es hauptsächlich.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von DJBase:

Zitat:

---

Original von whose:
Sagen wirs mal so: Die meisten Probleme, die auftauchen und auch den Micro betreffen _können_, sind softwaretechnischer Natur, Treiber etc. Die Hardware ist okay und schnell.

---

Hardwarefehler sind Probleme softwaretechnischer Natur? Vielleicht beim Entwerfen des Designs.

---

Zitat:

---

Wenn man all die Probleme, die der A1 (SE/XE/Micro) hat, einmal zusammenfasst, dann fällt mir außer Kopfschütteln wahrlich nichts mehr ein:

Northbridge fehlerhaft, Southbridge fehlerhaft, je nach Modell und in verschiedenen Kombinationen Probleme mit Sound, USB, Ethernet und DMA (nicht nur IDE-DMA), Probleme mit bestimmten Netzteilen und der Akku hat auch noch so seine Probleme im Micro. Habe ich etwas vergessen?

---

Ja, hast Du. Der "Akku" ist, wie beim PC und auch beim Peg, kein Akku sondern eine Lithium-Batterie. Ist die defekt, gibts Probleme. Hat Eyetech ne billige Charge von gekauft, na und? 2 EUR, und das Thema ist für die nächste 3 Jahre erledigt. Abgesehen davon ist das ein Problem, das wirklich nur wenige Micros betrifft (mir ist kein Micro mit dem Problem bekannt geworden, nicht mal auf AW. Da warens immer SE, die Sorgen mit der Batterie hatten und nach einem Austausch der selben wieder einwandfrei liefen).

USB-Problem beim SE/XE (NICHT beim Micro) ist bekannt und behoben. Alle weiteren Probleme rühren von den Treibern her (Du liest doch AW, liest Du das nur halb?). Ebenso das Problem mit den Soundblaster128, dessen nimmt sich Davey inzwischen an (_Soundblaster_-Bug mit nem Workaround beheben).

DMA macht keine Probleme, nur Linux ist nicht darauf eingerichtet, ohne Hardware-Cache-Coherency zu arbeiten (ja, ich weiß, es ist ein Bug des Articia. Allerdings nur aus Sicht von Linux), daher geht DMA dort nicht. Für die Linux-Fans sicher kein großes Problem, schließlich gibts das auch für x86...

Southbridge: Ja, die hat nen Bug, wie so viele andere Southbridges auch. Trotzdem wurde die in vielen PCs eingesetzt und selten hat sich jemand drüber beschwert.

Netzteil-Problem: Hast Du denn nicht gelesen, daß der Großteil dieser Netzteile auch an einem PC nicht ordentlich tut, ergo defekt sind? In meinem Micro steckt ein absolut billiges Scheiß-Netzteil drin (welches mit dem _Gehäuse_ geliefert wurde, nicht mit dem Board ), läuft prima. Aber ob das Ding wohl auch an einem stromhungrigen Standard-PC tut?

Zitat:

---

Ich würde das nicht als "Die Hardware ist okay und schnell." bezeichnen,
aber ist ja nicht mein Geld. Nur finde ich das unbegreiflich, wie man all das einfach so hinnehmen kann. Habt Ihr zuviel Geld oder nehmt ihr spezielle Medikamente? Wollt ihr keine Verbesserung?

---

Sicher wollen wir das. Und von uns hätten wohl wenige etwas dagegen, OS4 auf nem Peg laufen zu lassen. Aber erzähl das nicht uns sondern Amiga Inc./Genesi.

Abgesehen davon: Mein Micro tut seinen Dienst "okay und schnell", Bugs hat er keine, soweit ich das überhaupt feststellen kann (ich kann schließlich nicht in die Bauteile reingucken). Im täglichen Gebrauch funktioniert jedenfalls alles und es funktioniert gut.

Oder wie erklärst Du Dir z.B. Bootzeiten von <5 Sekunden mit aktiviertem DMA? Brennen mit MakeCD kein Problem? Surfen wie gewohnt, nur schneller? Musik hören wie gewohnt (sogar mit den gewohnten Problemen wie Abstürzen, das kenne ich schon vom 4000er, nur sind die Programme im Verhalten genau umgekehrt. AmigaAMP läuft auf dem 4000er problemlos, Amplifier stürzt ab, auf dem Micro genau umgekehrt. Ist natürlich die A1-_Hardware_, sonnenklar ). Ach ja, nen Kartenleser in den USB rammen und wieder rausziehen geht übrigens auch (es erscheint brav ein Icon auf der Workbench und verschwindet auch wieder). Und das sogar hne Hub und ohne Reparatur.

Ich sags mal so: Beim Peg ist man damals den einfachen Weg gegangen, weil man sich ja auch (oder soll ich sagen: NUR?) auf Linux konzentriert hat (wo ist denn nun MOS 1.5?). Da wars ein Bug des Articia, der kein DMA zuläßt. Merkwürdigerweise läßt er eben doch DMA zu, wie der A1 SE/XE/µ inzwischen zeigt. Die wirklichen Bugs des SE/1.Serie XE sind lästige Anlaufschwierigkeiten seitens Eyetech.

Hat jemand Wunder erwartet von einer 1-Mann-Firma?

Ich für meinen Teil kann jedenfalls nicht sagen, daß ich vom µA1 enttäuscht wäre. Eher positiv überrascht nach dem SE-Debakel.

Um einem letzten Gegenargument vorzugreifen: Nein, so lange es kein OS4 für den Peg gibt, kaufe ich mir auch keinen. Ich brauche MOS nicht, ich brauche Linux nicht. Welchen Wert hätte dann ein Peg für mich? Da müßte ich wohl tatsächlich spezielle Medikamente nehmen oder viel zu viel Geld haben, um einen Rechner zu kaufen, den ich in dieser Form nicht benutzen würde.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Kai9:

Zitat:

---

Original von whose:
Leider erwischt man die nie genau mit dem Slider

---

Habt ihr schonmal versucht, die Speed-Einstellung der Maus eine Stufe runter zu setzen, damit eine pixelgenaue Slidereinstellung möglich wird?

Kai


[ Dieser Beitrag wurde von Kai9 am 25.07.2005 um 12:06 Uhr editiert. ]

---

Jep. Leider bringt das nichts. Man kann auch einmal in den Container klicken, der Pixelclock-Wert springt sofort auf einen 0,10 MHz-Wert, so daß man glatte Werte (wie 108,00 MHz) nie erreichen kann

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Flinx:

Zitat:

---

Original von whose:
Des weiteren hat man mit nem LCD das Problem, daß durch den dussligen GUI-Fehler von P96Mode keine 100% korrekten Werte einstellbar sind, man liegt also immer haarscharf neben den Werten, mit denen der Monitor gut synchronisieren kann.

---

Ich hatte eine Zeitlang auch dieses Problem, bis ich festgestellt habe, daß man die Werte auch manuell eingeben kann und nicht auf die Felder zum Anklicken angewiesen ist (die immer nur größere Sprünge zulassen). Jetzt habe ich ein perfektes Bild auf dem TFT.

---

Hmm... das Problem ist hauptsächlich der Pixelclock-Wert. Ich hab schon viel damit rumprobiert, aber dort kann ich keinen Wert manuell eingeben.

Die anderen Werte betreffen mehr die Bildlage bzw. das Synchronisationstiming, aber leider nicht die Bildschärfe. Bei den LCDs kommts vor allem darauf an, daß der Pixelclock-Wert genau paßt. Das wäre z.B. bei einer VESA-konformen 1280*1024er Auflösung 108MHz. Leider erwischt man die nie genau mit dem Slider

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Zettmaster:
So...USB Funktastatur & Maus laufen, leider nicht in U-Boot...
Dort wird jetzt beim starten immer ein PS2 Keyboard abgefragt und nicht gefunden...

Wie kann ich das(selftest) ausstellen bzw die Tastatur auch in U-Boot benutzen...

---

Nochmal eine PS2-Tastatur anklemmen, in UBoot auf "Use USB keyboard" umstellen, dann sollte es funktionieren

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von DJBase:

Zitat:

---

Original von whose:
@DJBase:

Inwiefern bekannt?

---

So bekannt wie der Rest auch. Vielleicht ist ja auch nicht jedes Board davon betroffen.

---

Könntest Du hier vielleicht etwas konkreter werden? Welchen "Rest" meinst Du?

Mag sein, daß es bei wenigen µA1 Boards krasse Unterschiede bei den Signalwerten gibt, nur glauben kann ich das schlecht, bis jemand die Dinger durchmißt und das zweifelsfrei feststellt.

Was ich bisher gelesen habe sind Gerüchte/persönliche Vorlieben/Abneigungen, aber keine konkreten Hinweise auf fehlerhafte Schaltungen.

Das anfänglich matschige Bild rührt bei mir jedenfalls definitiv nicht von der Elektronik her, da es inzwischen auch auf dem LCD so scharf ist, wie es die "Haarscharf daneben"-Werte von P96 eben zulassen (ist halt doof, wenn der A/D-Wandler des Monitors auf VESA-Werte getrimmt wurde und man mit dem eigenen Signal knapp daneben liegt. Das kann nix Vernünftiges geben). An einem Röhrenmonitor war das Bild so gut wie das eines PCs mit Radeon 7000 AGP-GraKa (_nicht_ onboard). Ginge sicherlich noch einen Hauch besser, wenn die P96-Werte etwas feiner einzustellen wären.

Die gleichen Werte für die CVisionPPC unter CGFX eingestellt ergibt hier das gleiche "matschige" Ergebnis wie für den µA1. Somit liegts viel wahrscheinlicher an P96, weniger am µA1 und dessen onboard Radeon.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von DJBase:
Das mit dem leicht unscharfen Bild ist normal. Das liegt nicht an der Kantenglättung sondern am OnBoard Grafikchip.

---

Schuljung, wenn ich da mal zwischenfahren muß:

Ein Teil der Unschärfe geht definitiv auf die Kantenglättung zurück, das schrieb ich bereits in dem µA1-Artikel.

Probiers aus und benutze einen Windows-Port, der auf FreeType aufsetzt. Das Bild ist alles andere als scharf auf einem LCD. Antialias auf die altmodische Methode ist halt nicht das Gleiche wie ClearType

Des weiteren hat man mit nem LCD das Problem, daß durch den dussligen GUI-Fehler von P96Mode keine 100% korrekten Werte einstellbar sind, man liegt also immer haarscharf neben den Werten, mit denen der Monitor gut synchronisieren kann. Bemerkbar macht sich das vor allem dadurch, daß Teile des Bilds gestochen scharf sind, ein paar Zentimeter weiter wirds völlig verwaschen.

Inzwischen bin ich mit meinen Einstellungen so weit, daß das Bild alles in allem scharf ist. Allerdings muß man den Monitor oft mehrmals synchronisieren lassen, bevor sich die nötige Schärfe einstellt. Ich wette jedenfalls um ein Glas Bier, daß das Bild völlig ok ist, sobald man mal vernünftige Werte für P96 eingestellt kriegt.

Mein voriger PC hatte übrigens auch einen Onboard Radeon7000, da war das Bild an nem LCD prima. Noch dazu hatte der Hobel ne VIA Southbridge, genau wie der Micro

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

whose:
ich erinnere mich nur noch dunkel an das Poseidon-DevKit, da tauchte alle paar Zeilen ein "#ifdef" "DECLGATE"-Konstrukt auf.

---

Das hat was mit MorphOS zu tun.

---

Zitat:

---

Zitat:

---

Genau das ganze Drama erledigt bei WOS der Linker. Auch die Namensauflösung. Soweit ich mich erinnere, kommt vor jede ehemalige 68K-Funktion bei einem Mixed Binary ein _PPC..., darüber "weiß" der Linker ja Bescheid. Also kein Namenskonflikt.

---

Wie erkennt der 68k-Compiler, das eine PPC-Funktion aufgerufen wird? Oder erkennt das der Linker?

---

Das erkennt der Linker, da der Compiler die Funktionen als 68K (Standard- "_") oder eben als PPC-Code (wenn ich mich richtig erinnere "_PPC_") markiert, je nach dem, welche Compiler-Variante zum Einsatz kommt für das betreffende Modul/Funktion. Dementsprechend fügt der Linker die jeweils passende Gate-Funktion (bzw. die 68K-Funktion) für den Aufruf ein.

Das Erstellen der Gates passiert beim StormC im ersten Compilerlauf mit aktivem Debugging, dabei werden die Gatefunktionen automatisch als Source erzeugt, welche der Compiler dann zum Objekt compiliert.

So könnte man (theoretisch) auch den umgekehrten Weg gehen, also aus PPC-Code via Gate 68K-Code aufrufen. Und alles, ohne was an den Sourcen selbst verändern zu müssen...

Ansehen kannst Du Dir das an den Sourcen zur WOS-Version von der libmad, die ich Dir mal geschickt hatte. Kann ich Dir nochmal schicken, falls Du die nicht mehr haben solltest

Zitat:

---

Zitat:

---

Daher ists ja auch (eigentlich, die libmad z.B. weicht von dem Schema gewaltig ab ) simpel, aus 68K-Programmen WOS-Programme zu machen. Ein Compiler-Linker-Zyklus ohne Source-Anpassungen (man muß nur das Projekt mit ein paar Klicks umsortieren) genügt (normalerweise).

---

IMHO, der mpega_libmad Weg ist flexibler und man ist nicht an ein einziges Compilersystem gebunden.

---

Naja, das ist das Ergebnis der Uneinigkeit/der Grabenkämpfe. Wenn die Compiler an WOS angepaßt worden wären (so, wie sie im Endeffekt auch an die jeweiligen ELF-Varianten angepaßt werden mußten), würde sich diese Frage nicht stellen. Genauso könnte man argumentieren, wenn AmigaOS damals von Hunk- auf ELF-Format umgestellt worden wäre, was ja nun auch mit OS4 passiert ist.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 15.07.2005 um 18:13 Uhr editiert. ]

Zitat:

---

Original von gni:
Auch wenn Dir die IDE etwas Arbeit abnimmt, Gatefunktionen werden *auch* bei WOS benötigt. Wobei sich mir die Frage aufdrängt, die Gatefunktion bekommt den Namen der aufzurufenden Funktion, den den selben Namen als PPC Funktion hat. Wie löst man das Dilemma?

---

Das Gatefunktionen benötigt werden, stimmt. Allerdings muß man sie bei WOS nicht im 68K-Code einbauen, dort ist also _keine_ Anpassung nötig (ich erinnere mich nur noch dunkel an das Poseidon-DevKit, da tauchte alle paar Zeilen ein "#ifdef" "DECLGATE"-Konstrukt auf. Nicht besonders gut lesbar, wenn man nur an der 68K-Variante interessiert ist ).

Genau das ganze Drama erledigt bei WOS der Linker. Auch die Namensauflösung. Soweit ich mich erinnere, kommt vor jede ehemalige 68K-Funktion bei einem Mixed Binary ein _PPC..., darüber "weiß" der Linker ja Bescheid. Also kein Namenskonflikt.

Daher ists ja auch (eigentlich, die libmad z.B. weicht von dem Schema gewaltig ab ) simpel, aus 68K-Programmen WOS-Programme zu machen. Ein Compiler-Linker-Zyklus ohne Source-Anpassungen (man muß nur das Projekt mit ein paar Klicks umsortieren) genügt (normalerweise).

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
So ähnlich kann man es auch mit WOS machen, allerdings verlierst Du dann die simple Möglichkeit, fat binaries zu erzeugen.

---

Wieso, das entspricht doch so ziemlich einem fat binary, der Unterschied liegt doch nur darin, ob man zusätzlich zum ppc-code auch noch eine 68k-Version des entspr. Programmteils einbettet.

---

Zitat:

---

Zitat:

---

Zitat:

---

Klingt nach einer guten Sache. Ist wie immer eine Frage nach Aufwand und Resourcen.

---

Wenn ich genau wüßte, daß ich über kurz oder lang nicht ganz allein daran basteln muß...

---

Mich reizt das auch, aber mit freier Zeit sieht's ziemlich problematisch aus.

---

Hm, ich halts da mit "gut Ding will Weile haben". Wenn ich jemanden dabei hätte, mit dem ich mich austauschen kann und der mir dann und wann den Wald zeigt, den ich vor lauter Bäumen nicht sehe (und umgekehrt natürlich auch ), dann kommt Spaß an der Sache auf. Dann zählt die tatsächlich benötigte Zeit nicht so. Im Endeffekt verkürzt das die Zeit, die benöigt wird, weil entsprechend Motivation da ist.

Ich denke mal nicht, daß man in dieser Hinsicht unbedingt was vom Zaun brechen muß. Hauptsache, es passiert überhaupt was. Ist allerdings meine rein persönliche Sicht der Dinge, ich weiß nicht, wie Du das siehst.

Zitat:

---

Zitat:

---

Hm, ich denke, so aufwändig ist ein Debugger auch wieder nicht. Zumindest muß er ja nicht aus dem Stand heraus "full featured" und perfekt sein, oder?

---

Bei einem Debugger ist die erste Minimalversion das schwierige, insb. wenn man den code nicht debuggen kann...

---

Das ist wohl wahr. Andererseits sind inzwischen genug Techniken bekannt, die sowohl in der Theorie als auch in der Praxis funktionieren. Vielleicht mache ich mir die Sache hier etwas zu einfach, aber wenn man den Debugger nach praxiserprobten Theorien baut, dürfte auch die erste Version (mit minimalem Funktionsumfang) nicht so besonders schwierig auf die Beine zu stellen sein. Darauf aufzubauen und weiterzuentwickeln ist dann, denke ich, auch nicht mehr so schwer.

Abgesehen davon sind für alle Systeme bereits Debugger/Tools vorhanden, die man zum Debuggen des Debuggers einsetzen könnte

Ich schätze mal, da schlägt die Crux Amiga wieder zu: Der Anfang ist das schwierigste, weniger wegen der Technik sondern mehr wegen dem inneren Schweinehund

Interesse an der Sache habe ich jedenfalls, und ich lerne immer gern dazu. Nen Debugger habe ich noch nie selbst gebaut. Von nem kompletten IDE ganz zu schweigen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Solar:
Ich mein' das jetzt ganz ernst, weil ich nicht ganz auf dem Laufenden bin: Wie sieht es eigentlich mit Java-Unterstützung auf AOS4 / MOS aus? Ist da überhaupt etwas in Arbeit?

Dann könnten sich echte Optimisten ja auf Eclipse als IDE freuen...

---

Guggst Du hier.


Aber für Elipse muß man wirklich noch ein echter Optimist sein

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Nein, streng genommen ist das einzige Problem, den PPC-Code ins Hunk-Format zu kriegen und dann einen passenden Linker zu haben, der daraus (ggf. zusammen mit 68K-Code) ein funktionsfähiges Executable macht. Ich entsinne mich noch dunkel an die "Krücke" aout2hunk für die ersten AOS68K-GCCs...

---

Hmm, ich kann mich erinnern, daß ich damals für powerup eine ziemlich einfache Lösung hatte, bei der das ELF binary, so wie es war, in das 68k Programm eingebettet wurde. Ganz so, wie mancher größere textpassagen oder Bilddaten included hat.
Die powerup-lib hatte eine Funktion, die das ELF-file auch direkt aus dem RAM laden konnte.

---

Zitat:

---

Zitat:

---

Um ehrlich zu sein: Mir persönlich wäre es lieber, wenn man die adtools-Initiative nutzt, den GCC immer fein aktuell hält in allen Geschmacksrichtungen und dazu passend eine schöne, leicht bedienbare und komfortable IDE zimmert.

---

Klingt nach einer guten Sache. Ist wie immer eine Frage nach Aufwand und Resourcen.

---

Wenn ich genau wüßte, daß ich über kurz oder lang nicht ganz allein daran basteln muß...

Zitat:

---

Zitat:

---

Die könnte man wahlweise auch in 68K halten, da dieses ja auf allen Systemen (Ausnahme AROS, aber das sollte kein großes Problem sein) läuft. Dann leidet die Geschwindigkeit gerade auf echten 68K-Systemen zwar spürbar, aber wozu gibts WinUAE/Amithlon?

---

Leidet die Geschwindigkeit auf echten 68K-Systemen, weil es die Software dann überhaupt für solche Systeme gibt? Oder meinst Du, weil alle Entwickler nur an 68k-emu Systemen arbeiten und keiner mal auf "classic" testet?

---

Weder noch. Wenn Du den 2.95.x-GCC mal auf nem 060er laufen läßt, weißt Du, was ich meine. Da war der StormC3 schon ein wenig im Vorteil, weil viel schneller. Leider kann der in Sachen C++ halt nicht mithalten. Noch krasser wirds mit dem GCC 3.x, wie das mit dem 4.x aussieht, will ich ehlrich gesagt gar nicht wissen

Die IDE ist, wenn man nicht gerade krampfhaft portabel arbeiten muß, das geringste Problem dabei

Zitat:

---

Zitat:

---

Oder man baut ein Amiga-spezifischer Debugger, der sich einfach in eine solche IDE einbinden läßt.

---

Ja wenn wir alle mehr Zeit hätten... Auf Schlaf, Freizeit und Job kann man ja verzichten...aber selbst dann sind's nur 24h/d.

---

Hm, ich denke, so aufwändig ist ein Debugger auch wieder nicht. Zumindest muß er ja nicht aus dem Stand heraus "full featured" und perfekt sein, oder?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 14.07.2005 um 09:13 Uhr editiert. ]

Zitat:

---

Original von Holger:
Soll heißen, mit WarpOS als target? Inwieweit braucht man eigentlich tatsächlich aktiven support dafür?
Letztendlich gibt's ja auch ne pup-emu. Also prinzipiell kann man auch konventionellen ppc-code ausführen und alles, worum es Programmierern geht, ist doch ppc-code und 68k-code in einem executable zu verpacken, dem man von außen nicht ansieht, was da alles kompliziertes passiert, oder?
So etwas könnte man doch mit einem amiga-spezifischen tool machen, das man in der build-chain ganz ans Ende stellt, ohne den gcc überhaupt anzufassen.
Oder geht's noch um irgendetwas anderes?

---

Ja, da gehts um einiges anderes Nein, streng genommen ist das einzige Problem, den PPC-Code ins Hunk-Format zu kriegen und dann einen passenden Linker zu haben, der daraus (ggf. zusammen mit 68K-Code) ein funktionsfähiges Executable macht. Ich entsinne mich noch dunkel an die "Krücke" aout2hunk für die ersten AOS68K-GCCs...

Ich denke allerdings nicht, daß sich der ganze Aufwand wirklich lohnt. Für die wenigen WOS-Programme, die heute noch gepflegt werden, kann man (immer noch) den StormC3/4 nehmen, OS4/MOS/AROS etc. pp. kommen mit dem einfacher anzupassenden Standard-GCC ja bereits prima klar.

Um StormC4 (bzw. dessen IDE) an OS4 anzupassen ists vor allem notwendig (soweit ich es verstanden habe), den Debugger aus der ganzen IDE auszuklammern (der würde unter OS4 eh nicht mehr tun und hatte in der 68K-Fassung so seine Probleme mit dem GCC-Code) und den GCC mit einem ARexx-Port zu versehen, damit die Storm Shell an die Fehlermeldungen herankommt.

Um ehrlich zu sein: Mir persönlich wäre es lieber, wenn man die adtools-Initiative nutzt, den GCC immer fein aktuell hält in allen Geschmacksrichtungen und dazu passend eine schöne, leicht bedienbare und komfortable IDE zimmert (vielleicht mit Hilfe der Leute, die die Werkzeuge in deep kennen? ). Die könnte man wahlweise auch in 68K halten, da dieses ja auf allen Systemen (Ausnahme AROS, aber das sollte kein großes Problem sein) läuft. Dann leidet die Geschwindigkeit gerade auf echten 68K-Systemen zwar spürbar, aber wozu gibts WinUAE/Amithlon?

Einziges Sorgenkind wäre dann nur noch der GDB, dem bessere Bedienbarkeit durchaus gut zu Gesicht stünde.

Oder man baut ein Amiga-spezifischer Debugger, der sich einfach in eine solche IDE einbinden läßt.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 14.07.2005 um 01:25 Uhr editiert. ]

Zitat:

---

Original von Solar:
Soweit ich mich erinnere, kann StormC nicht einmal die STL fehlerfrei compilieren (die immerhin seit mehr als sieben Jahren zum C++-Standard gehört!).

---

Zitat:

---

Und in Astyle habe ich immer noch ein #ifdef drin, weil die mit dem gcc2 ausgelieferte C++-Lib die Parameter zu einer so "esoterischen" Funktion wie string::compare() wohl gerne in einer anderen Reihenfolge hätte als der Standard.

---

Zitat:

---

Ob das immer noch der Fall ist? Keine Ahnung, gcc 2.95 benutzen heute wohl nur noch wirklich verzweifelte Menschen.

---

Zitat:

---

Und was das Installieren angeht... meine letzten beiden Installationen einer GCC-Umgebung sahen so aus:

emerge gcc (Gentoo Linux)
iexplore http://www.cygwin.com/setup.exe (Windows)

Wer da auf GCC schimpft, schimpft auf den falschen.

---

Wer in einem Amiga-Forum mit Installation eines Unix-Paketes nach Linux-Manier als Beispiel kommt, schimpft im falschen Forum

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Das Ergebnis kann man ja sehen, WOS ist tot, StormC ist tot und wo das ABI von WOS dem Programmierer mehr Komfort gibt als das von powerup, kannst Du ja gerne belegen. Für einen normalen C-Programmer ist das *ABI* etwas, das er überhaupt nicht wahrnimmt. Außer dann, wenn er unnötige Arbeit aufgehalst bekommt, weil ein Compileranbieter unbedingt ein nicht-standardkonformes verwenden mußte.

---

Du meinst unnötige Arbeit wie die Rücksichtnahme auf Gate-Funktionen bei 68K-Libraries mit PUP Unterstützung? Oder das üble Rumgetrickse mit CallHook()? Das braucht man bei WOS z.B. nicht.

Das Ergebnis, daß WOS tot und Storm auf Eis gelegt ist, ist wohl weniger auf den PUP/WOS-Krieg zurückzuführen, als mehr auf den allgemeinen Niedergang des Marktes. Unter anderem aufgrund zwar interessanter, aber eben nutzloser Grabenkriege, nicht nur zwischen WOS/PUP-Verfechtern.

Eben sowas ähnliches wie das, was Du hier gerade betreibst (GCC rulez, alles andere suckt).

Reichts Dir denn nicht, daß man inzwischen mangels Alternativen nicht mehr am GCC vorbeikommt? Und ob man nun den StormC-GCC benutzt oder den blanken CLI-GCC, das ist doch wohl nun wirklich eine Frage der persönlichen Vorlieben und Möglichkeiten.

Programme, die laufen, kommen aus beiden heraus. Für meine Zwecke ist der StormC-GCC besser, weil schneller und komfortabler zu bedienen. Für andere ist der CLI-GCC mit make und dem ganzen Drumherum besser.

So einfach ist das.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:
Wenn die Wahl falsch gewesen wäre, dann würde heute niemand dieses Modell benutzen. Es ist aber weit verbreitet!? Und welche Wahl soll es denn gegeben haben? Damals gab es nix. Mit hypothetischen Weiterentwicklungen kann man nix anfangen.

---

Zitat:

---

Zitat:

---

Der Hemmschuh ist schlicht und ergreifend die fürchterlich Unix-orientierte Installation & Bedienung des GCC.

---

Die einen lieben es, die anderen nicht.

---

Jep. Aber denen, die es nicht lieben, wirds aufgezwungen und mögliche andere Optionen erstickt. So geschehen beim Storm. Mag sein, daß der StormC3 nicht besonders gut ist, aber dafür comiliert er um den Faktor 6-10 schneller. Mit ein bißchen Zeit und Geld zur Weiterentwicklung...

Zitat:

---

Zitat:

---

Oder was meinst Du, warum viele Profi-Entwickler auf den MS-Compiler und dessen IDE schwören? Nur weils so schön bunt ist? Oder könnte etwas dran sein, daß ne IDE den Arbeitsfluß verbessert?

---

Welchen Umkehrschluß soll ich jetzt ziehen? Kein MS-Compiler+IDE == kein Profi?

---

Zitat:

---

Zitat:

---

Apropos: mpega LibMad war mit dem Storm in <30 Sekunden zusammengeklickt.

---

Nur komisch das es mit den Originalquellen trotzdem nicht lief. Und es haben ja mehrfach Leute versucht, eine WOS Version mit StormC zu erstellen, ohne Erfolg .-)

---

Weil die Originalquellen eigentlich gar nicht darauf ausgelegt waren, eine WOS-Version zu erzeugen. Daß das trotzdem (auch mit den Originalquellen!) funktionierte, war ein ganz besonders finsterer Trick. Erinnerst Du Dich? Die "24Bit-Reloc"-Warnungen einfach überlesen und nochmal compilieren

Zitat:

---

Zitat:

---

Wäre das #ifdef-Wirrwarr nicht gewesen, wäre die in einer Minute fertig compiliert.

---

Wie macht man es besser? Die Bibliothek ist für mehrere Systeme gedacht und so muß man irgendwie kappseln.

---

Meiner Meinung nach wäre es schlauer gewesen, die libmad-Teile komplett vom Library-Gerüst zu trennen. Auf dem Weg kann man dann (wie es der Storm-WOS für mixed binaries/Libraries erwartet) einen 68K-Teil und einen PPC-Teil getrennt compilieren. Da brauchts das #ifdef-Chaos höchstens im Library-Teil, wobei die WOS-Version dem Compiler als gewöhnliche 68K-Library (mit eingebetteten PPC-Funktionen) erscheint.

Der große Nachteil von PUP war halt, daß man bei Libraries ziemlich aufwendig mit Gate-Funktionen arbeiten muß. Das kannst Du Dir unter WOS sparen, denn das erledigt da der Linker

Wenn ich mal etwas Zeit finde, kümmere ich mich nochmal darum, die Trennung zu erledigen. Dank Deiner Aufräumarbeit kann man die Sourcen jetzt wenigstens gut lesen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von AlexanderK:

> P.S.: [...] Apropos: Hast Du die Update-Patches eigentlich installiert, falls Du eine ältere Version bekommen hast? Die Updates findest Du bei H&P im Support-Bereich...

Bingo! Das war der Tipp, den ich gebraucht hatte. Ich glaubte zwar, dass ich die letzte Storm Version hatte, dem war aber nicht so. Ich habe wohl die zweite von drei Versionen und da gibt es ein Update bei H&P.

---

Ah, dann hast Du diese unsägliche Mittelversion erwischt. Ja, die läuft leider nicht allzu gut

Zitat:

---

Als ich das installiert hatte, gab es zwar keine Fehler mehr, aber er mekerte eine fehlende ixemul.library an. Das hatte er vorher noch nie gemacht? Ich hab mir also aus dem Aminet die Bibliothek gezogen installiert und siehe da, ich war wieder ein Stück weiter. Denn jetzt suchte der den Datenträger AmiTCP? Ich also mal auf gut Glück den TCP Stack von der AmigaOS CD installiert... und was soll ich sagen whose? Es läuft! Er kompiliert und kompiliert... ist zwar nicht der schnellste, aber es läuft!

---

Genesis basiert auf AmiTCP Die ixemul.library wird für das CVS-System benötigt und der TCP/IP-Stack für das verteilte Make, also StormServer etc. Daß der nicht besonders schnell ist, hast Du dem GCC zu verdanken, der als Port leider etwas lahm arbeitet. Dafür kriegt der wenigstens auch solche Feinheiten wie die STL für C++ durch, daß packt der StormC3 leider nicht.

Zitat:

---

Ich danke dir noch mal für den entscheidenden Tipp.

---

Kein Thema. Freut mich, daß ich helfen konnte

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von AlexanderK:

Natürlich, leider war ich zu bl.d die Meldungen zu kopieren. Ich hab daher nur mal zwei exemplarisch aufgeführt (die ersten zwei). Danach geht es munter weiter die ganze Header-Datei lang.

--
Message: In file included from HelloWorld.c, line 1
HelloWorld.c, line 1
--
Error: At top level:
parse error before 'size_t'
...include/stdio.h, line 61
--
Warning: At top level:
function declaration isn't a prototype
...include/stdio.h, line 61
--

---

Hm, die Meldung kenne ich... allerdings wundert es mich etwas, daß diese Meldung bei stdio.h kommt... probier mal folgendes:

Bei den "Compiler"-Optionen, da wo "NDEBUG" eingetragen ist, trägst Du einfach mal folgendes nach:

NO_INLINE_LIBCALLS

in exakt dieser Schreibweise. Wenn dann die Meldungen verschwinden, solltest Du Dein Programm nochmal überprüfen, vor allem, welches printf() Du verwendest.

Die Meldung, wie Du sie oben angegeben hast, kommt im allgemeinen nur bei den Includes der dos.library, also dos/dos.h und ähnliche. Verursacht wird die durch fehlerhafte Includes, wobei sich der Compiler besonders an den "Ersatz-Macros" stört (das wäre z.B. Printf(), beachte, daß hier das P großgeschrieben ist, bei der Version aus stdio.h mußt Du das P klein schreiben!).

Vielleicht sollte ich mich doch endlich mal daran machen, die Includes zu korrigieren und die Macros wie Printf() GCC-gerecht umzubauen...

Grüße

P.S.: Falls das nichts bringen sollte, schick mir doch bitte mal Dein stdio.h zu, dann steckt der Fehler da drin. Frag mich aber nicht, wie der da hinkommt, diese Includes sind beim StormC4 korrekt. Apropos: Hast Du die Update-Patches eigentlich installiert, falls Du eine ältere Version bekommen hast? Die Updates findest Du bei H&P im Support-Bereich...

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 12.07.2005 um 02:05 Uhr editiert. ]

Zitat:

---

Original von gni:

Warum war/ist es für einen Teil ein Hemmschuh? Ich finde es zeigt auf jeden Fall das die Wahl von P5 begründet war. Seinen eigenen Compiler zu pflegen ist ein sehr aufwändige Sache. Da fällt mir ein: 64bit LinuxPPC benutzt das PowerOpen-ABI ;-)

---

Zu dieser Zeit war die Wahl am Markt vorbei, denn da gab es noch Compiler, die weiterentwickelt wurden.

Der Hemmschuh ist schlicht und ergreifend die fürchterlich Unix-orientierte Installation & Bedienung des GCC. Frag doch mal nen Anfänger, ob der mit dem Compiler gut klarkommt und sich damit wohlfühlt. Jede Wette, die Antwort wird lauten "Der Compiler ist viel zu kompliziert, damit machts nicht wirklich Spaß zu arbeiten". Oder schau Dir die Anzahl der Fragen hier im Forum an, wie man dieses Monstrum korrekt installiert

Oder was meinst Du, warum viele Profi-Entwickler auf den MS-Compiler und dessen IDE schwören? Nur weils so schön bunt ist? Oder könnte etwas dran sein, daß ne IDE den Arbeitsfluß verbessert? Apropos: mpega LibMad war mit dem Storm in <30 Sekunden zusammengeklickt. Wäre das #ifdef-Wirrwarr nicht gewesen, wäre die in einer Minute fertig compiliert. Und ich habe dabei kein vorgetippertes Makefile benutzt

Übrigens, FLDev auf OS4 ist derzeit noch keine Alternative, da kann man von Glück reden, wenn man mal ein Projekt ohne Absturz zusammengestellt, getippt und compiliert kriegt. Da ist noch ne Menge zu tun, finde ich. Wenn, dann schon eher GoldED. Nicht so schöne Bedienung, aber funktioniert wenigstens (aber ich benutze den (noch) nicht)

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von AlexanderK:

Jemand eine Idee, was ich da so grundlegend falsch mache?

----
#include <stdio.h>

int main() {
printf("Hello World.");
return 0;
}

---

1. sollte es main(void) heißen, das gibt zwar nicht zwingend eine Meldung, ist aber sauberer.

2. Schau mal in den "Projekt Environment"-Settings, ob der korrekte Include-Pfad eingetragen ist, der sollte "StormC:Include" heißen.

3. Wären die Meldungen selbst sehr interessant, nicht, daß bei Dir die Installation selbst fehlerhaft ist (kann schon mal vorkommen).

Hoffe, ich konnte etwas helfen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Zitat:

---

Hast Du die WOS-Version der mpega-LibMad aus den entrümpelten Sourcen bekommen?

---

Habe ich. Die funktioniert auch, aber ich bin bei "meinen" Versionen geblieben ;-)

---

Kein Thema, wollt nur wissen, ob die auch angekommen ist

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:
@whose:

Hi, machs doch mit ner Hookfunktion für den ScreenModeRequester. Dann kannst Du die Modi bestimmen, die überhaupt zur Auswahl stehen (z.B. alle mit genau 8Bit Farbtiefe und und und).

---

Jep, das habe ich nun gemacht. Leider ohne Ergebnis Der Screenmode stimmt, allerdings sieht die Grafik weiterhin alles andere als gut aus. Vorerst habe ich zu Testzwecken einen Punkt über den Screen wandern lassen (der jeweils nicht mehr benötigte Punkt im Hintergrundbuffer wird gelöscht), was auf den anderen Maschinen bestens funktioniert.

Auf WinUAE zieht der Punkt eine flackernde Linie hinter sich her, die offensichtlich vom zweiten Buffer herkommt, dort also aus irgendeinem Grund nicht gelöscht wird.

Zur Erläuterung: Ich arbeite ohne Fenster (input.device-Handler ), zeichne also direkt in die Screen-Bitmap (was laut Autodocs ja kein Vergehen ist ). Es sieht ein wenig so aus, als würde WinUAE (bzw. uaegfx.card) die Paletten für die Buffer durcheinanderschmeißen

Lustigerweise funktioniert das andere Programm (das auf CGFX umgestrickte DoubleBuffering-Demo von der DevCD) bis auf den flackernden Mauszeiger bestens. Allerdings wird da nur mit dem Blitter gearbeitet, nicht mit SetAPen() & Co. sowie nicht mit Move()/Draw()-Kombination (bzw. diese Funktionen werden auf eine nicht sichtbare Bitmap angewandt).

Weiß einer, worans liegt? Ich weiß so langsam nicht mehr weiter Wenns mit reinem Blittereinsatz tut, solls mir auch Recht sein. Wäre halt nur schön, wenn man für andere Dinge alle Optionen der graphics.library offen hätte. Aber ich hab echt keine Ahnung mehr, warums unter WinUAE nicht will, auf allen anderen Maschinen schon

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:
Die Anpassung des GCC2 WOS-Compiler ist leider nicht so einfach möglich, wie die der PUP Variante (die gibts von GCC2 bis GCC4).

---

Warum eigentlich nicht? Die Sourcen des Storm-GCC sind doch vorhanden. Mit ein bißchen Know-How...

Zitat:

---

Zitat:

---

Ist ja auch noch in Arbeit, daher "so lange StormC _nicht_ für OS4 verfügbar ist"

---

Ich wollte eigentlich etwas mehr zu dem Thema hören ;-) Wer macht das, welche Compiler Version, welches ABI (StormGCC steht ja mehr für WOS als PPC). Für mich klingt das ganze nach OS4 GCC in der StormIDE :-)

---

Wer? Gute Frage, ich hab den Namen gleich wieder vergessen, nachdem ich den auf dem OS4-Event in Essen gehört habe. Einzelheiten sind mir auch nicht bekannt, weil ich damit wenig zu tun habe. Ich denke aber, daß Du mit Deiner Vermutung ins Schwarze triffst: StormC-IDE für den OS4-GCC. Das wäre so ziemlich das, was man bräuchte und was relativ einfach machbar wäre. StormC-WOS ginge zwar jetzt theoretisch auch, aber der alte Storm-Debugger funkt dazwischen.

Und dann vielleicht noch nen schönen Debugger mit GUI statt des Krampf-Kommandozeilen-GDB dazu...

Grüße

P.S.: Ich hatte vor einiger Zeit in nem anderen Thread schon gefragt: Hast Du die WOS-Version der mpega-LibMad aus den entrümpelten Sourcen bekommen?

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 11.07.2005 um 13:03 Uhr editiert. ]