Zitat:

---

Original von Reth:

Als Betaversion sollten USB2.0-Treiber doch schon im Test sein! Und da ich Betatester bin...

---

Zitat:

---

Original von eliotmc:
@roper67:
Eigentlich ist das völlig egal,
es sind beide sehr stabile Karten.

Achte nur darauf, dass du eine Ariadne 2 erwirbst,
die 1 hat keinen RJ45 Anschluss.

---

Zitat:

---

Original von ZeroG:
Cool.
Funktioniert das nur auf dem Peg oder auch auf dem A1 und den SAMs?

---

Nur mit dem Peg (daher auch der Name "pegoff" ).. bzw. nur mit Open/SmartFirmware, weil das Tool einfach einen "power-off" RTAS Aufruf macht, genau wie das Ambient->Verlassen->Abschalten Menü unter MOS.

Zitat:

---

Original von Reth:
Nun würde ich ihn gern per Software runterfahren und das ATX-Board ausschalten lassen statt mich immer zu verbiegen und den Taster zu drücken, bis er abschaltet!

Gibt es so ein Tool für AOS4 irgendwo? AOS4Depot hat mir nix dazu ausgespuckt!

---

Zitat:

---

Original von Bjoern:
Oh, das tut mir leid. Vielleicht muss ich mal gucken ob die mir nicht durch den Filter gegangen ist. Ich meld mich...

Gruß,
Björn

---

Habs Email nochmals verschickt.
Hoffe es kommt jetzt an.

Zitat:

---

Original von Kronos:

Also ein Device gehöhrt nach devs: (eventuell noch ein Unterverzeicniss)
oder eben in ein ROM. Es mag zwar Ausnahmen geben, aber solange ich
nicht weiss worum es hier eigentlich geht ....

---

Zitat:

---

Also was du willst scheint ja sowas wie usbpar.device zu sein, und
da denke ich du solltest das einfach über den Installer lösen
"Wollen sie den Treiber für den TCP/IP-Fön, oder nicht ?",
und damit hats sich. Wenn jemand doch das Device öffnet ohne das
der Fön angeschlossen ist, gibt es eben die entsprechene Fehler-
meldung (DOS-Code 2666 "no fön available" ).

---

Eben.. Du sagst es, sowas wie usbparallel.device... und das ist
eben *nur* dann im System vorhanden/sichtbar, wenn ein USB-Drucker
angeschlossen ist. Ist keiner da, gibt es das Device auch nicht.
Es wird eben dynamisch zur Verfügung gestellt und liegt nicht
im Devs: rum...

--
Bye,
Cyborg
-- We would die for

Zitat:

---

Original von thomash:
Das Assemblerbeispiel ist eigentlich recht gut dokumentiert, die Umsetzung in C sollte nicht so schwer sein. Aber Assembler sollte man vielleicht doch dazu können, zumindest ansatzweise...

---

Da ich in Assembler eine Null bin (welch Wortspiel ), tu ich mir da verdammt
hart.. aber das Beispiel war auch das erste, was ich mir zu dem Thema angesehen
hab..

Es muß da doch auch was in C geben, oder??

Zitat:

---

Ansonsten habe ich vorhin mal kurz die Autodocs überflogen, es gibt ein AddDevice()/RemDevice() in exec, wie bei einer Library. Die Vorgehensweise zum dynamischen Einklinken in das System müsste auch die gleiche, wie bei einer Library sein.

Und auch Devices kann man entfernen, wie eine Library. Bei den Beispielen zum serial.device war eine kleine Funktion dabei, wie das geht. Eigentlich genauso, wie bei der Library: Expunge() aufrufen.

---

;-) Ja .. das hab ich kurz nach dem Abschicken meiner letzten Nachricht ebenfalls
entdeckt ... muß mir endlich angewöhnen, etwas genauer zu lesen..

Zitat:

---

Ein Device in eine Library zu stecken, macht eigentlich nur noch Sinn, wenn man eine alte Library ersetzen will, weil ein Device praktischer wäre, um die Hardware anzusteuern.

---

Da ich im Device - egal, ob stand-alone im Devs: oder nicht - sowieso auf Funktionen
in meiner Treiber-Lib zugreifen müßte, dachte ich eben, daß ich die Device-Schnittstelle
gleich in die Library packen und damit zwei Fliegen mit einer Klappe schlagen kann
(1. Zugriff auf die Funktionen und 2. Device nur "sichtbar", wenn auch HW verfügbar
ist).
Anscheinend war das wohl keine so gute Idee ..

Zitat:

---

Ich kann mir allerdings nicht vorstellen, daß irgendjemand mal eine Hardware nicht direkt per Device angesteuert hätte, sondern den "Umweg" über eine Library gegangen ist.

---

Nimm als Beispiel USB.. da hast Du keine andere Möglichkeit, als den eigentlich
Treiber in eine Library zu packen und die Befehle wiederum über eine Library (dem Stack)
an die Hardware zu schicken.

Der User (Coder), der jetzt diese von Dir unterstützte Hardware benutzen möchte,
muß ebenfalls über die Stack-Library und evtl. deine Treiber-Library gehen, um
die HW nutzen zu können...

Genau dafür würde ich eben geren ein Device bereitstellen, damit 1. die Handhabung
für Dritte einfacher fällt und 2. auch ältere Programme ohne Rework sofort die
Hardware benutzen können (sofern sie über Devices arbeiten).

--
Bye,
Cyborg
-- We would die for

Zitat:

---

Falsch. Jedes devices wird von einer übergeordneten Instanz geladen und wieder entfernt. Das funktioniert über den gleichen Mechanismus wie bei libraries.

---

Dies hast Du eindeutig *falsch* verstanden. Der Stack *erfordert*, daß der
eigentliche Hardware-Treiber eine Library ist. Daran beißt die Maus keinen
Faden ab.
Natürlich stimme ich Dir bei der Aussage grundsätzlich zu, aber in diesem
Fall ist sie einfach fehlangebracht.

Was den "Totalen Unfug" angeht, hast Du eigentlich nichts anderes gesagt,
als ich es getan habe.. Nur daß ich eben das Device auch nur dann zur
Verfügung stellen wollte, wenn die Hardware da ist und nicht erst bei einem
Zugriff darauf checken..

Zu der Dateistruktur.. das bezog sich auf die Vorgabe, daß es *kein* #?.device
im Devs: gibt, sondern das Device eben in einem anderen Stück Code untergebracht
ist. Und dieses Stück Code hätte keinen *vernünftigen* Platz, der die angedachte
Verteilung der Dateien des Stacks *nicht* durcheinanderbringen würde.. da
habe ich herzlich wenig damit zu tun.

Es ist richtig, daß ich den User für "dumm" halte.. allerdings *konstruktiv* !
Ich versuche Software zu schreiben, die möglichst DAU- und narrensicher ist..
dadurch können ein Haufen Probleme von vornherein vermieden werden.
Das ist IMO keine Beleidigung des Users, sondern vielmehr eine Vereinfachung
für den User.. es beschränkt sich ja nicht nur auf das Verstecken von Devices,
wenn sie nicht benötigt werden, sondern erstreckt sich über ein viel größeres
Gebiet.
Um Dein Beispiel aufzugreifen: wenn ein User "dir devs:" macht, will er - wie
Du selbst geschrieben hast - wissen, welche Devices *installiert* sind.. sprich:
welche Devices hat er zur Verfügung. Ein Device hat er aber nur zur Verfügung,
wenn er auch die entsprechende Hardware dafür hat. Wenn also diverse Devices
existieren, die der User gar nicht nutzen *kann*, weil die Hardware eben *nicht*
zur Verfügung steht, warum sollten sie dann aufgelistet werden? (Nicht vergessen,
wenn die HW nicht da ist, wird auch der HW-Treiber nicht geladen und damit auch
das Device nicht zur Verfügung gestellt - sollte es in dem Treiber eingebettet
sein).
Aber natürlich sehe ich auch Deinen Standpunkt.

Abschließend: Richtig, ich wollte Antworten auf meine Fragen. Von deinen
Empfehlungen fühlte ich mich allerdings leicht angegriffen.. vielleicht habe
ich dabei etwas überreagiert, kann sein.. in dem Fall, entschuldige. Trotzdem
wären mir handfeste Quellenverweise (Device-Coding in C, etc.) lieber, als
so lapidare Sprüche, wie "Vielleicht solltest Du mehr Anstrengungen...".

Ich würde sagen, wir begraben hier und jetzt unser "Kriegsbeil" .. schließlich
will ich nicht streiten, sondern etwas lernen..


--
Bye,
Cyborg
-- We would die for

Zitat:

---

Original von Holger:
Tja, ganz offensichtlich bist Du gerade dabei genau das Gegenteil zu entwickeln, einen aufgeblähten Library-Code, in dem nicht benötigte devices eingelagert sind, egal ob sie benötigt werden oder nicht.
Vielleicht solltest Du mehr Anstrengungen unternehmen, das device-system des Amigas zu verstehen, in dem das dynamische Nachladen bereits seit über zehn Jahren problemlos funktioniert, anstatt dieses umständliche Handling entwickeln zu wollen, das keinerlei erkennbaren Vorteil bietet.

---

Oh, Vergebung!
Vielleicht sind Eure Hoheit so gändig und erleuchten unseren kleinen Geist ein
wenig, damit wir Eurer Weisheit ein wenig näher kommen, obgleich wir sie niemals
werden erreichen können?!


Im Ernst, anstatt hier nur groß heiße Luft zu versprühen und zu versuchen, mir
meine Arbeit madig zu machen, wären konstruktive Vorschläge weitaus sinnvoller!
Du solltest vielleicht auch erstmal genauer nachfragen, bevor Du meckerst..

z.B. habe ich die Kapitel über Devices im RKRM Devices und RKRM Libraries genau
gelesen... leider steht da aber nur, wie man ein Device *benutzt*, nicht, wie
man eines selbst *programmiert* und schon gar nichts von dynamisch erzeugten
Devices.
Jedenfalls hab ich nichts darüber gefunden, außer einem Assembler-Beispielcode
für ein Custom-Device, mit dem ich aber mangels Assembler-Kenntnisse nichts
anfangen kann..

Nebenbei hast Du anscheinend nicht verstanden, worum es hier eigentlich geht,
also nochmal, nur für Dich: Es wird ein Treiber für eine bestimmte Hardware
benötigt, der von einem übergeordneten Stack geladen oder auch wieder entfernt
wird. Daher *muß* es eine Library sein. Punkt.
Das nächste ist, daß dem User auf einfache Weise Zugriff auf diese Hardware
gestattet werden soll. Das geht nuneinmal am besten über eine deviceähnliche
Schnittstelle.
Natürlich könnte ich darauf verzichten, aber dann wäre jedem älteren Programm,
das nicht mehr gepflegt wird, der Zugriff auf die Hardware versagt. Inzwischen
ist der Anteil der nicht weiter gepfegten Software am Amiga so groß, daß dies
völlig inakzeptabel ist.
Da also die Library nur geöffnet wird, wenn auch die Hardware vorhanden ist,
macht es natürlich Sinn, wenn auch das Device nur dann verfügbar ist. Also
dynamisch erzeugt wird (siehe z.B. duart.device oder auch das usbparallel.device
von Chris Hodges).
Leider sieht es so aus, daß ich keine Möglichkeit habe, den Code für das Device
in einem Verzeichnis bereitzustellen, sodaß ich ihn immer finden kann und
vor allem die Dateistruktur *nicht* durcheinander bringe. Also muß der Devicecode
in der Library eingebettet sein.
Natürlich kommt jetzt von Dir wahrscheinlich wieder, daß ich ein komplettes
Device schreiben und es im DEVS: ablegen soll. Schön und gut, wenn aber keine
Hardware vorhanden ist (was wohl öfter vorkommt, da sie relativ selten ist),
würde dieses Device bei vielen einfach nur rumgammeln und evtl. für Verwirrung
sorgen.

Abgesehen davon, macht es öfter Sinn ein Device dynamisch dem System hinzuzufügen.
Und dieser Mechanismus würde mich *generell* interessieren.. im Moment eben aus
einer Library heraus, ansonsten eben aus einem normalen Programm heraus.


So, jetzt sollte es auch der Letzte verstanden haben, um was es geht. Es ist
wirklich traurig, daß man hier genauso angepflaumt wird, wie in den Kommentaren
zu irgendeiner News-Meldung, wenn mal etwas nicht nach dem Geschmack gewisser
Personen hier ist... tolle Community..

--
Bye,
Cyborg
-- We would die for

Zitat:

---

Original von thomash:

Also quasi wie eine Decoder-Library, die entweder per Software (Library) funktioniert, oder Hardware-beschleunigt, wenn die Karte dazu vorhanden ist.

---

Zitat:

---

Stack ? Also irgendwas mit USB oder Netzwerk ? Oder beides ?

---

Hehe... das möchtest Du jetzt gerne wissen, gell
Vielleicht isses ja auch was völlig anderes



--
Bye,
Cyborg
-- We would die for

Zitat:

---

Original von thomash:
zu 2.: Eigentlich macht es keinen Sinn, ein Device aus einer Library heraus zu erzeugen, da ein Device praktisch eine aufgebohrte Library ist. Ein Programmierer muß nur das Device öffnen und den LibNode einer Basisvariablen zuweisen, wie bei den Libraries, schon sind die "Library"-Funktionen zugänglich. Siehe das Beispiel timer.device in den RKMs.

---

Zitat:

---

Aus reiner Neugier: Was ist das denn für eine Hardware, die so ein Vorgehen verlangt ?

---

Is (noch) geheim ;-)


--
Bye,
Cyborg
-- We would die for

Zitat:

---

Original von Askane:

Vielleicht ist der Fehler sehr simpel, das mir das vorher nicht
auffiel. Benenne doch mal die new_emubox in emubox.gz um. Also
Orginal.

---

Hat etwas gedauert, bis ich dazugekommen bin, das auszuprobieren..
Aber wie erwartet, hat das auch nicht geholfen ... immernoch
Checksum error on kernel image von Isolinux


--
Bye,
Cyborg
-- We would die for