Zitat:

---

Original von Cego:
@whose:
weißt du was das schlimme daran ist? ne ganze community musste ihn motivieren damit er weitermacht und einer machts kaputt

---

Zitat:

---

das ist eigentlich ne Sache zwischen ihm und PAB. ist nicht unser bier, weswegen ich aber auch sagen muss, dass grad deswegen dieser thread unnötig ist, wobei ja sein thread gelöscht wurde. man kann sich drüber streiten.

---

Zitat:

---

aber wie ich bereits sagte am besten ist es immer noch solche leute zu ignorieren die einem auf die eier gehen

---

Stimmt, das wäre erste Wahl gewesen. Das hat aber nicht den gewünschten Effekt: Ein kleines Heer von zu Kreuze kriechenden Anwendern kann man mit schlichtem Ignorieren nicht erzeugen.

Bei Ego-Problemen, wodurch auch immer diese zum Tragen kommen mögen (wie gesagt, ich glaube nicht so wirklich an die Mär von "nur PAB ist Schuld", meiner Meinung nach steckt da zusätzlich noch etwas ganz anderes hinter), ist es natürlich was Feines, wenn hundert Leute ankommen und betteln, daß man doch nicht aufgeben möge, alles halb so wild sei blablabla.

Nur: ist es die Aufgabe "dieser Community", sich um die recht persönlichen Probleme eines Entwicklers zu kümmern, indem sie Bauchpinselei betreibt, wenn dieser Entwickler mit einer leicht verminderten Form der Erpressung um die Ecke kommt, und sich damit dessen Willkür und Launen immer mehr auszuliefern?

Ich denke nicht.

@Chris:

Ok, das wars dann wohl... machs gut, vielleicht sehen wir uns irgendwann mal wieder in "dieser Community". Würde mich, trotz des Heckmecks, sehr freuen, irgendwann einmal wieder gute Produkte von Dir zu registrieren. Sofern Du es schaffst, Deine Probleme mit gewissen Leuten zu lösen, ohne alle anderen mit hineinzuziehen und verantwortlich zu machen für Deinen persönlichen Kram.

Das hat "diese Community" nämlich wirklich nicht verdient und auch nicht nötig.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 30.10.2007 um 19:56 Uhr geändert. ]

Zitat:

---

Original von platon42:

Zitat:

---

Original von gunatm:
Selbst wenn du Recht hättest, sieht das wie billige Rache aus. Hast du das nötig? Ich will ein Nein hören.

---

Was ich sicher nicht nötig habe, ist mich mit dieser "Community" (oder was da so an Leuten übrig geblieben ist) abzugeben. Das war sicher mein letztes Produkt für den Amiga.

Du willst ein Nein hören? Nein, ich lasse mich nicht erpressen oder auf diese Art und Weise zensieren.

---

Du lieber Himmel... "diese Community" hat sich mit Dir eine ganze Weile abgegeben, das Schmierentheater mit Poseidon68K hingenommen und Dich bekniet, weiterzumachen. Was erwartest Du jetzt eigentlich von uns? Das wir alles kritiklos hinnehmen, was Du im Zorn verbockst?

Ich hatte ja bereits geschrieben, daß es durchaus in Ordnung geht, wenn Du einen schlechten Tag hast und denke, daß man da schnell mal etwas macht, was so ganz sicher nicht von der "freien Meinungsäußerung" abgedeckt ist.

Aber verdammt nochmal, das war keine Meinungsäußerung, die Du da losgelassen hast, das war (und ist) klipp und klar eine Beleidigung, Rufschädigung und was weiß ich, was Dir ein mittelmäßiger Anwalt im Normalfall dafür "reindrücken" würde.

Was ist eigentlich so schwer daran, einfach mal etwas Dampf abzulassen, auf wirklich gutgemeinte Ratschläge anderer zu hören (sprich: die Beleidigung aus dem ReadMe herausnehmen oder wenigstens so weit entschärfen, daß sie wirklich als "freie Meinungsäußerung" durchgehen würde) und vor allem: Nicht alle über einen Kamm zu scheren.

Es ist ja keineswegs so, daß Dir jeder hier (und aus "dieser Community" allgemein) ans Bein pinkeln will... im Moment tust Du aber so, als wären ausnahmslos alle Amiganer "Trolle und Idioten" (Zitat) von dem Kaliber, daß Dir so schwer zu schaffen macht. Sind sie aber nicht.

Also, sei bitte so fair und halte "diese Community" in ihrer Gesamtheit aus diesem Kindergarten-Scheiß heraus. Es gibt durchaus Sachen, die Du nicht verdient hast (gewisse Firmen, gewisse Leute), aber es gibt auch Sachen, die wir nicht verdient haben.

Z.B. als Ablaßventil für Deinen Zorn herhalten zu müssen, und das nicht zum ersten Mal.

Wie schon erwähnt, wenn Du der Ansicht bist, daß Reden hilft, dann sag das bitte. Ich bin bereit, da noch ein Mal als Teil "dieser Community" meinen aktuellen Zorn runterzuschlucken und mit Dir darüber zu reden. Aber nach dieser Aktion und nach diesen Worten über "diese Community" ist das definitiv das letzte Mal, ich lasse mich nämlich auch nur äußerst ungern erpressen.

Grüße

--
---

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

Zitat:

---

Original von jolo:

Hmmm, da habe ich aber Mist gebaut wenn's keiner versteht...
Software-Interrupts werden natürlich auch von einem Hardwarebaustein generiert, allerdings liegt es am Betriebssystem die Hardwarekomponenten auszuwählen, die für diesen Vorgang nötig sind.

---

Mir war das soweit schon klar, es ist nur schwer zu vermitteln über den Beispiel-Code Der Beginner sieht nur, daß da ein Signal vom timer.device gesendet wird und denkt im ersten Moment "Ah, wie ich das vorher auch schon gemacht habe. Wozu dann aber den SoftInt? Welchen Gewinn habe ich dadurch? Ist ein SoftInt wirklich was ganz anderes als ein normaler Task? Wieso nicht direkt die CIA-Timer und deren Interrupt nutzen?"

Es ist ja nicht so, daß man jedes winzige Detail dieses Ablaufs erklären müßte, aber ein grober Überblick über die tatsächlichen Abläufe kann nie schaden und hilft u.U. auch beim Verständnis von fortgeschritteneren Techniken.

Zitat:

---

Zitat:

---

Wenn ich ehrlich bin muß ich sagen, daß ich dieses Beispiel für Anfänger wesentlich schwerer zu durchschauen finde, weil dort nicht so wirklich klar wird, auf welche Weise der SoftInt "aufgerufen" wird bzw. was diesen Interrupt eigentlich auslöst.

---

Da gebe ich Dir vollkommen Recht. Das Problem bei der Amiga-Programmierung ist, dass wir immer verstehen wollen, wie was funktioniert, weil wir auch immer die Strukturen von Hand initialisieren müssen. Unter anderen Betriebssystemen benutzt man Funktionen, die keinen Einblick auf die Zugrunde liegenden Eigenschaften gewähren, also mehr oder weniger Black-Boxes nacheifern.

---

Das ist leider so unter anderen OSsen und führt auch oft zu einem völligen Mißverständnis der zugrunde liegenden Prinzipien. Ich denke, grundlegendes Verständnis der Technik kann nie schaden, Vorteile von Blackboxes hin oder her. Ich habe festgestellt, daß Blackbox-Prinzipien immer erst dann verstanden werden, wenn man tiefer in die Materie eingestiegen ist und die Probleme selbst kennengelernt hat, die bei "Hardware-Banging" auftreten. Learning by doing

Ging mir selbst übrigens auch oft so

Zitat:

---

Das Amiga-Betriebssystem ist eigentlich sehr ausgeklügelt angelegt, was die Effizienz der Hardware angeht - es gibt natürlich auch hier Ecken und Kanten - allerdings mangelt es an Dokumentationen, wie man was verwenden soll.

---

Zitat:

---

Wir benutzen z.B. das Timer-Device um eine gewisse Zeitspanne zu warten, ohne zu Wissen, dass es den CIA-A Baustein in Beschlag nimmt.
Wir benutzen das Timer-Device um Interrupts zu generieren, ohne zu Wissen, dass es entweder den CIA-A/CIA-B Baustein oder auch die Video-Hardware benutzt, um in bestimmten Zeitabständen eine bestimmte Aktion zu tätigen.

---

Zitat:

---

Zurück zu unserem Beispiel.
Wie oben eingeräumt, gebe ich Dir vollkommen Recht; das Beispiel ist wirklich nicht ganz einfach zu verstehen.

Es wird ein "echter" Interrupt generiert - allerdings nur einmal aufgerufen (StartIRQ).
Da wir einen wiederkehrenden Interrupt benötigen, jedoch unsere Interrupt-Routine nur einmal aufgerufen wird, greifen wir zu einem Trick. Wir starten innerhalb unseres Interrupts unseren Interrupt erneut - dabei sagen wir dem Timer-Device, dass es erst nach soundsovielen Sekunden uns erneut aufrufen soll.
Nachdem dies geschehen ist und unser Interrupt beendet wurde, vergehen soundsoviele Sekunden bis unser Interrupt erneut aufgerufen wird - und wir wiederholen das Prozedere.

---

Ja, der Teil ist eigentlich leicht verständlich Man fragt sich als Anfänger aber automatisch, was die Quelle des Aufrufs ist, sieht nur das Signaling, kümmert sich nicht weiter um die "Kleinigkeit" PA_SOFTINT und spart sich darüber dann auch die Mühe, das nicht ganz einfach verständliche Kapitel "Exec: Interrupts" in den RKMs gründlich zu lesen, weil das ja dem normalen Task-Signaling sehr ähnlich ist. Daß das timer.device in diesem Fall mit Cause() statt Signal() arbeitet, bekommt man gar nicht mit

Zitat:

---

Nehme an, Du müsstest in einer Schleife jedes Mal 400 Millisekunden warten um irgendeinen Wert, der sich alle 400 Millisekunden ändert, zu lesen. Im Prinzip rufst Du dann auch immer DoIO() auf - vorher hast Du die "Auszeit" mit 400 Millisekunden festgelegt.
Im Prinzip verwenden wird das Gleiche für unseren Interrupt, sagen aber dem Timer-Device, dass es keinen Prozess/Task etwas signalisieren soll (mp_SigTask), sondern einem Interrupt (PA_SOFTINT) und verwenden nicht DoIO sondern BeginIO.

---

Und hier wird es dann endlich klar, daß der SoftInt wirklich ein Int ist, der via Cause() gestartet wird

Zitat:

---

Zitat:

---

Ich denke nicht, daß ein Unerfahrerener so ohne weiteres kapiert, daß dieser "Interrupt" quasi wie ein normaler Task via Signal vom timer.device "aufgeweckt" wird (was ja keineswegs der landläufigen Vorstellung von einem Interrupt entspricht).

---

Wie gesagt, deshalb habe ich ja auch versucht zu erklären, warum ich so gerne das Ganze abstrahiert hätte. Ist mir ganz klar nicht gelungen.

---

Zitat:

---

Ich hätte zudem darauf hinweisen müssen, dass nicht das Timer-Device den Interrupt auslöst sondern nur anfordert.
Auslöser ist Cause() - und das verursacht den Level-1 Interrupt - durch das Setzen des 2. Bits im INTREQ Register ($DFF09C). Damit ist wiederum der Hardwarebaustein gefunden, der erst einen Level-1 Interrupt unter Classics ermöglicht, Agnus.

---

Ah, und wieder ein Anhaltspunkt mehr für ausgiebige Lektüre der RKMs mit ein klein wenig Hintergrundwissen Jetzt verstehe sogar ich wieder ein klein wenig mehr, was mir vorher nie so ganz klar geworden ist. Danke schön!

Zitat:

---

Ich fand das erste Beispiel jedenfalls schön praxisbezogen und gut dokumentiert, Abstraktion wie im letzten Beispiel ist eigentlich ein Thema für fortgeschrittenere Programmierer und für seine Zwecke auch gar nicht wirklich nötig.

---

Zitat:

---

Wie gesagt, den Datentyp wollte ich verstecken - das geht aber nicht bei nur einem Quellcode...
Stelle Dir vor, die drei Funktionen wären in einer Link-Lib. Der Datentyp den InitIRQ() zurückgibt würde in einer Include-Datei mit "VOID *" spezifiziert anstatt mit "struct TimeOutIRQData *" - und nur die drei Funktionen wüssten, das "VOID *" in Wirklichkeit "struct TimeOutIRQData *" wäre. Wäre es dann nicht extrem leicht für einen Nutzer, diese Funktionen zu verwenden?

---

Wäre es ohne VOID * auch, zumindest für AmigaOS-Gewöhnte

Aber hast schon Recht, bei konkreten Implementierungen muß man nicht unbedingt wissen, wie sie intern funktionieren. Deine Erläuterungen hier haben aber definitiv dazu beigetragen, die Abläufe im OS und die Stolperfallen, die auf einen lauern können, besser zu verstehen, da bin ich absolut sicher. Nochmals vielen Dank dafür!

Grüße

--
---

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

Zitat:

---

Original von jolo:

Zitat:

---

Groß auf Funktion testen konnte ich es mangels Sampler allerdings nicht ;-)

---

Da seit Jahren mein A4000 im Keller verbannt ist, kann ich es auch nicht mehr testen...
Und meinen Digitizer an den PC anschließen - hmmm, nicht mein Ding. :}

---

Zitat:

---

Zitat:

---

Ein Knackser zum Start dürfte aber darauf hinweisen, daß es versucht, Audio abzuspielen. Beenden ließ es sich mit Break-C ebenfall problemlos.

---

Ja, das Knacksen bedeutet, dass Daten an die Harware transferiert werden. Müsste aber schnell vorbei sein - es werden ja keine unterschiedliche Werte gelesen.

---

Ein "Knackser" ist per (Audiophilen-) Definition kurz Aber richtig, danach ist Ruhe.

Zitat:

---

Zitat:

---

Nachtrag: Es scheint aber die Sound-Emulation von WinUAE zu beeinflussen, der Windows-Sound klingt reichlich verbogen nach Start des Audio-Grabber. Eine Ahnung, was dafür verantwortlich sein könnte?

---

Das ist ein Fehler von WinUAE bzw. Windows-XP. Auch ohne AudioGrabber passiert dies bei mir hin und wieder. Meistens reicht es aus, WinUAE neu zu starten. Wenn's dann noch nicht klappt, PC neu starten...
Entweder dies ist ein Initialisierungsfehler von WinUAE oder es hat mit dem unzureichenden Timing unter XP zu tun.
Windows ist nicht gerade ein Timing-Weltmeister.

---

Zitat:

---

Zitat:

---

Sehr schönes Beispiel für Interrupts in C übrigens, vielen Dank dafür!

---

Man sollte den Code mit Vorsicht genießen - er ist dermaßen hardwarenah geschrieben, dass der Interrupt weder unter Amithlon, OS4 noch MorphOS zum Laufen gebracht werden kann. Erstens gibt es dort keine CIAs, noch ist "poken" dort erlaubt.
Da allerdings der parallele Port direkt ausgelesen wurde, gehe ich davon aus, dass die Hardwarevoraussetzungen für diesen Typ von Interrupt erfüllt sind.

---

Zitat:

---

Ein schönes Beispiel, in meinen Augen, folgt jetzt.
Dieses benutze ich in abgewandelter Form in echten Applikationen.
Sollte unter OS4, Amithlon und MorphOS auch laufen.
Es ist ein Level-1 Interrupt - somit können gefahrlos andere Interrupts von diesem aus aufgerufen werden. Zudem wird selbst bei rechenintensivem Code innerhalb des Interrupts das System nicht schwerwiegend beeinflusst, da ja alle systemkritischen Interrupts mit einer höheren Priorität arbeiten. Nur Prozesse laufen mit einer niedrigeren Priorität.

---

Wenn ich ehrlich bin muß ich sagen, daß ich dieses Beispiel für Anfänger wesentlich schwerer zu durchschauen finde, weil dort nicht so wirklich klar wird, auf welche Weise der SoftInt "aufgerufen" wird bzw. was diesen Interrupt eigentlich auslöst. Es wird auch nicht ganz klar, welchen Nutzen man daraus ziehen kann, daß "andere Interrupts" davon aufgerufen werden können.

Für die Vorstellung Vieler dürfte ein Interrupt etwas "im Wesen deutlich verschiedenes" zu Tasks/Prozessen sein, diese Beispiel zeigt aber im Grunde (korrigiere mich, wenn ich da falsch liege) einen Task, der teilweise aus dem "normalen" Multitasking rausgenommen und auf Interrupt-Ebene verlagert wurde.

Ich denke nicht, daß ein Unerfahrerener so ohne weiteres kapiert, daß dieser "Interrupt" quasi wie ein normaler Task via Signal vom timer.device "aufgeweckt" wird (was ja keineswegs der landläufigen Vorstellung von einem Interrupt entspricht).

Da war das CIA-abhängige Beispiel schon etwas informativer bzw. einfacher zu begreifen, finde ich.

Ok, MaikG hat noch so seine Probleme mit dem Verständnis, das liegt aber wohl eher an mangelnder Erfahrung mit C und mit dem System AmigaOS (er hackt ganz gern ).

Ich fand das erste Beispiel jedenfalls schön praxisbezogen und gut dokumentiert, Abstraktion wie im letzten Beispiel ist eigentlich ein Thema für fortgeschrittenere Programmierer und für seine Zwecke auch gar nicht wirklich nötig (mal davon abgesehen daß ihm derzeit noch das Verständnis für Blackboxes fehlt)

Mit etwas mehr Erläuterungen, zum Beispiel wofür sowas wie ein SoftInt eigentlich gut ist und wie man den, außer in Verbindung mit dem timer.device, in der Praxis nutzt, ist es aber sicherlich auch ein sehr schönes Beispiel für Interrupts in C

Grüße

--
---

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

Zitat:

---

Original von Mika:

Zitat:

---

Original von Marcus:
@Mika:

ich meinte ja auch nicht das der in einen pc tower soll,...

ich dachte nur das es eventuell einen atx tower gibt, der baugleich ist, und als ersatzteilspender dient...

---

Ich habe bis heute keinen Tower gefunden wo die Maß halbwegs passen würden da der Elbox 23 cm breit ist!

---

Er hätte schmaler sein können (ganz so hoch ist das Konstrukt aus MoBo und Zorro-/Mediator-Daughterboard nicht), aber das hätte eine Umarbeitung des Blechs der Rückseite bedingt, die über das Stanzen neuer Löcher für die Amiga-MoBo-Anschlüsse hinausgeht, weil man bei moderneren Towergehäusen weniger Platz für die Anschluß-Durchbrüche zur Verfügung hat.

Noch dazu ist einem oftmals die Deckelfalz des Seitendeckels im Weg, da müßte man ebenfalls Ausbrüche machen usw.

Das haben die sich mit diesem fetten Monster gespart, denn der hat von vornherein genug Platz für die Anschluss-Durchbrüche auf der rechten Seite (wenn man sich das anschaut sieht man, daß neben der Falz des Seitendeckels weit mehr als ein Zentimeter Platz ist, was bei modernen Gehäusen nicht der Fall ist. Da konnte man recht bequem die Rückseite abnehmen, die zusätzlichen Löcher stanzen und die Rückseite dann wieder draufnieten).

BTW., der Elbox-Tower ist kein ATX-Tower, sondern ein AT

Grüße

--
---

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

Zitat:

---

Original von Mirko_Naumann:
Also mein 4000T war wohl auch aus der letzten Produktion. Auf dem sind nur zwei Pins (so wie für Jumper), an denen ein Stecker mit Batterie 3,6 V angesteckt war. Daher war es total simpel, ein Batteriefach mit Batterien anzuschließen.

Mein 1200er hat ein Mikronik Z3 Board für 4000er Turbokarten. Mit Uhr ist da nix. Deswegen mußte ich ein Uhrmodul auf den Uhrenport stecken. Und da ist nix mit Ladefähigkeit gewesen.

Aber gut - wieder was dazu gelernt: es gibt verschiedene Versionen.

---

Ja, das ist richtig... und irgendwie hast Du das Kunststück hinbekommen, nur batteriegepufferte Uhren zu haben. Das gibt es auch nicht oft

Trotzdem ist bei den Classics ein Akku (bei den älteren Amigas NiCd in Tonnenform, bei den neueren auch oft Lithium in Eine-Knopfzelle-Form, was man ja leicht mit einer Knopfzellen-Batterie verwechselt) deutlich häufiger anzutreffen als eine nicht-wiederladbare Alkali-Batterie in Knopfzellenform. Ich habe hier z.B. nur akkugepufferte Uhren in meinen A1200/4000/600/1000. Ich hatte in der ganzen Zeit nie eine Uhr/Uhrenerweiterung mit Knopfzellen-Batterie in irgendeinem meiner Rechner verbaut.

Als kleinen Anhaltspunkt kann man ja nochmal auf das Unterscheidungsmerkmal hinweisen: Knopfzellen mit einem U vor der Nummer sind Akkus, CR XXXX sind nicht-wiederaufladbare Batterien.

Nicht, daß sich jemand aus Unwissen mal eine TK mit Uhr oder einen 4000T der ersten Serie "sprengt".

Grüße

--
---

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

Zitat:

---

Original von Sperrmuell:

Zitat:

---

Original von whose:
Selbst bei den RAM-Erweiterungen war es eher ungewöhnlich, die Uhr mit einer Knopfzelle zu füttern, bei den 500ern noch weit seltener zu finden als bei den 1200ern und auch dort war das eigentlich ziemlich selten.

---

Beim A1200 wohl kaum, da gibt es dutzende Ram-Erweiterungen, die alle eine Knopfzelle haben (u.a. von Phase5, DKB, Micronik, Microbotics, M-Tec, Elsat). Beim A500 trifft dies schon eher zu.

---

Bist Du Dir da sicher, daß es sich dabei nicht um Akkus handelt?

Wechselbare Knopfzellen-Batterie habe ich nur bei der DKB-Erweiterung und bei der von Mikronik gesehen, ansonsten sind die "Knopfzellen" grundsätzlich fest verbaut, geklebt oder gelötet.

Wir hätten uns wohl vorher darauf einigen sollen, ob es nur um die Bauform oder doch mehr um die Batterie-Technik gehen soll. Mir ging es darum, daß die meisten Erweiterungen einen Akku (wenn auch aus Platzgründen meist in Form einer Lithium-Knopfzelle) besitzen und keine Batterie.

Es wäre nicht das erste Mal, daß jemand versucht, den platten Panasonic U2020/U2032-Akku auf einer Blizzard12x0-TK mit einer Knopfzellen-Batterie zu ersetzen, weil er es nicht besser weiß.

Grüße


--
---

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

Zitat:

---

Original von Sperrmuell:
Der A4000T hat von Hause aus eine Lithium Batterie, da liegt natürlich kein Ladestrom an. Das gilt auch für den A4000D Rev.D mit gleicher Batterie.

Alle anderen Modelle, die von Werk aus eine Batterie bzw. Akkumulator haben, wie A500+, A2000, A3000D, A3000T und A4000D habe alle Ladestrom.

Wie das Dritthersteller auf deren Produkte gelöst haben ist sicher wieder eine ganz andere Sache.

---

Mag sein, daß ich mich jetzt irre, weils wirklich schon lange her ist, aber die ersten Serien-A4000T hatten wohl durchaus noch Ladestrom, der per nachträglich eingelöteter Diode "deaktiviert" wurde, um die (billigeren) Knopfzellen einsetzen zu können.

Ich erinnere mich dunkel an eine Anleitung in irgendeinem Magazin, um den Kisten wieder einen Akku statt der Knopfzelle zu verpassen und den "Aufschrei", dens davor gab, als man bei Vorstellung der Serienmodelle die Knopfzelle statt des noch in den kurz zuvor gezeigten Vorserienmodellen des T vorhandenen Akkus entdeckte...

Selbst bei den RAM-Erweiterungen war es eher ungewöhnlich, die Uhr mit einer Knopfzelle zu füttern, bei den 500ern noch weit seltener zu finden als bei den 1200ern und auch dort war das eigentlich ziemlich selten.

Da Mirko aber wohl genau diese Konstellationen hatte, sei es ihm verziehen, daß er diese "Warnung" abgegeben hat. Ich selbst kenne sämtliche Modelle der Classic-Reihe bis auf den 4000D Rev. D und die zur selben Zeit hergestellten 4000T nur mit Akku und hatte auch nur eine einzige RAM-Erweiterung mit RTC für den 1200er auf einer der Köln-Messen in der Hand, die keinen Akku trug.

Grüße

--
---

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

Zitat:

---

Original von Neodym:

Zitat:

---

Original von Bluebird:
was mir aber sofort aufgefallen ist das die 3d wohl die einzige karte war bei der mit cgx screen drag wieder geht

---

Das geht nicht nur auf der CV3D. Das liegt an CGX, welches auf fast allen "alten" (Amiga-)Graphikkarten Screen-Dragging ermöglicht. Erst ab der CVPPC ging das nicht mehr, weil bestimmte Hardwarefunktionalitäten in den Graphikchips nicht mehr vorhanden sind. Und ein Workaround in Software wäre zu aufwendig geworden bzw. hätte unter mangelnder Rechenleistung der Amiga-Hardware gelitten.

---

*hust* Um genau zu sein, es ging eigentlich nur auf den beiden Zorro-CyberVisions und der Merlin (2? Weiß ich gar nicht mehr so genau, ist lange her), weil diese Karten eine dem Screendragging entsprechende Funktionalität in Hardware hatten.

Auf den Tseng- oder ET-basierenden Karten geht das Screen-Dragging auch mit CGFX nicht. Wäre mir jedenfalls neu, daß man mit einer Picasso2 Screendragging unter CGFX veranstalten könnte.

Möglich, daß es auch mit noch älteren Karten wie denen von GVP ging, das kann ich aber beim besten Willen nicht sagen, da ich diese Karten nie selbst in Aktion erlebt habe.

Grüße


--
---

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

Zitat:

---

Original von MaikG:

So, habs nochmal getestet:

code:

---

WHILE myseconds%<10
        POKEW tr& + IORequestio_Command%, TR_ADDREQUEST&
        POKEL tr& + tr_time% + tv_secs%, 0&
        POKEL tr& + tr_time% + tv_micro%, 44& REM 125=8000Hz
        SendIO&(tr&)
        INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds% REM 11.39   
        junk& = WaitIO&(tr&)
        REM INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds%    rem 11.41   11.46 mit DOIO
      WEND

---

Also keine großen berechnungen, nur die sekundenzählung.
Bei 10sek mit 44 micros, entweder 11.39 sek oder 11.41(siehe Position).
Wie erwähnt, sind aber 44 keine 8000 HZ sondern wesentlich mehr.
Bei 125 komme ich auf etwa 18 sekunden.
In dem Minicode kann ja kaum ein Fehler sein.

---

Naja, in dem Minicode an sich nicht. Ok, die 8000 ist etwas "daneben", weil man bei 44 auf irgendwas um die 22KHz kommen müßte.

Nur verstehe ich wirklich nicht, wieso das nur bei Dir wesentlich langsamer läuft. Der "Minicode" läuft bei mir (gemessen mit EClock) auf dein paar Mikrosekunden genau und man kann das Spielchen bequem bis zu einem Wert von 22 treiben (wahrscheinlich auch noch wesentlich weiter), ohne daß sich an der Genauigkeit etwas ändert.

Allerdings habe ich keine Ahnung, was MaxonBASIC (das verwendest Du doch?) daraus macht...

Grüße

--
---

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

Zitat:

---

Original von Mad_Dog:
Ich habe mir nochmal meinen Code von damals angeschaut.

Zur Erinnerung poste ich hier nochmal die Stelle, wo ich die Daten für ein Zeitfenster einlese:

...

Wie man sieht, hole ich den Wert vom Parallelport (ja, böse - ich lese direkt aus dem CIA-Register), sende dann ein Timer-Request und warte dann, bis ich eine Antwort erhalte. Optional hätte ich das Auslesen des Wertes auch zwischen dem SendIO und WaitIO machen können, wenn ich davon ausgehe, dass das fix genug geht.

---

So hätte ich das auch gemacht. Was ich mich allerdings bei den Samplern frage ist folgendes: Geht die Wandlung da immer mit "Fullspeed" oder wie wird das gehandhabt? Ich stelle mir das eigentlich immer als getakteten Vorgang vor und was passiert dann, wenn man mit dem Auslesen des Werts "außerhalb" des Wandlertakts liegt?

Was mir noch an Maiks Code aufgefallen ist: Er benutzt immer noch UNIT_ECLOCK, obwohl man ihm damals schon gesagt hat, daß UNIT_MIKROHZ praktikabler ist (und nicht ungenauer).

@MaikG

Benutz doch bitte mal UNIT_MIKROHZ, wie Mad_Dog es hier zeigt. Und bitte spiel das Sample erst nach dem kompletten Sample-Vorgang ab, um das zu überprüfen. Ich wette, da leiert es auf einmal nicht mehr.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Was darauf hinweist, daß Dein Timing (aus welchem Grund auch immer) unregelmäßig abläuft.

Sagte ich doch. Ich möchte sagen der Code ist von dir.

---

Zitat:

---

Übrigens wird bei Multimon - 18000 HZ eine CPU Last von ganzen
5% angezeigt.

---

Wo kann man dieses ominöse Multimon eigentlich herbekommen? Ich habe gestern schon mal danach gesucht, aber finde nichts dergleichen, nur Zeugs für Multi-Monitor-Betrieb.

Ich persönlich glaube nämlich nicht daran, daß es ohne den Timer-Interrupt des CIAs arbeitet. Übrigens, man kann seine eigene Interrupt-Behandlung in eine sog. Interrupt-Server-Chain einhängen, das wird also nicht unbedingt als richtiger Interrupt angezeigt und inwieweit Scout das anzeigt weiß ich auch nicht.

Maik, ich kann Dir immer noch nur folgenden guten Rat geben: Untersuch Dein Programm genau, erkläre nicht alle, die Dir nicht auf Anhieb helfen können für inkompetent und vor allem setz die Ratschläge doch einfach mal so um, wie sie Dir gegeben werden.

Dein BASIC-Programm von oben läuft jedenfalls nicht so, wie man es Dir angeraten hat, im Gegenteil. Und es ist auch nicht das, was man Dir in dem DTMF-Thread als Hinweis gegeben hat.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Der Leiereffekt kommt dadurch genauso zustande wie das scheinbar
>ungenaue Timing-Verhalten (das Problem in dem Thread damals, was
>wir dann ja zu einem großen Teil "beheben" konnten).

Da gings um zu große abweichungen beim Timing. Ein Prog was
halbwegs was erkennt lief nur auf den 68060. Das halbwegs
wird dann auch vom leiern sein.

---

Zitat:

---

>Stell Dir ein Zeitdiagramm mit senkrechten Flanken vor, die Plateaus
>geben an, wie viel Zeit ihm bleibt, um einen Wert ans audio.device
>weiterzureichen

Es leiert auch wenn ich eine Sekunde Sample, 1 Sekunde wiedergebe und
dann wieder Sample. Also keine Audiowiedergabe während des Samplen.

---

Zitat:

---

Über Interrupts hab ich nicht wirklich was gefunden, aber das
Programm Multimon(macht in etwa das selbe) setzt lt. Scout zumindest
kein Interrupt.

---

Gut, dann wissen wir noch mehr. Es geht also, auch ohne Tricksereien mit dem CIA. Da bleibt dann nicht mehr viel, MultiMon müßte demnach auch mit dem timer.device arbeiten und vor allem entweder mit der UNIT_ECLOCK oder UNIT_MICROHZ, den UNIT_VBLANK wäre für den Zweck nicht geeignet.

Am Sinn meiner Antwort ändert das jedenfalls nichts. Irgendwo hast Du eine Unregelmäßigkeit in Deinem Timing, die mußt Du finden.

Schau Dir doch nochmal den Thread von damals an, Mad_Dog hat, wenn ich mich recht erinnere, genau aus diesem Anlaß, ein kleines Sampler-Programm geschrieben. Das funktioniert recht gut und die Sourcen kannst Du Dir auch ansehen. Eventuell fällt Dir dann ein Unterschied zu Deinem Programm auf.

@Mad_Dog:

Ich habe nicht gesagt, daß das unmöglich wäre. Ich habe nur gesagt, daß es nicht trivial ist.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Du referierst doch so gern über Standards, dann schau doch mal in den (soweit ich weiß 1991 endgültig festgelegten) ANSI-Standard für BASIC rein. Da findest Du einiges, was Du der Sprache BASIC immer und immer wieder (durch schlichte Weglassung eben dieser Tatsachen) absprichst.

---

Wo kann man das denn nachlesen? Ich mein, außer durch Kaufen eines in der Praxis irrelevanten Buches?

---

Zitat:

---

Zitat:

---

Da wären u.A. zu nennen: Lokale Variablen, Funktionen, Typprüfung und Vorabdeklaration.

---

Gewiss doch, es gibt einiges. Solange aber z.B. Vorabdeklaration nicht zwingend ist, stellt sie nur überflüssige Schreibarbeit dar.

---

Zitat:

---

Zitat:

---

Wenn Du allerdings nur das Minimal-ANSI-BASIC betrachtest, hast Du zweifellos Recht. Nur ist da die standardisierte Entwicklung von BASIC halt nicht stehengeblieben, wie Du es immer wieder so gern kolportierst.

---

In der Praxis schon. Zumindest was standardkonforme Features angeht.

---

Zitat:

---

Zitat:

---

Diese Art der Weiterentwicklung hat es übrigens bei nahezu allen Programmiersprachen gegeben und oftmals haben sich Hersteller von Compilern/Interpretern über die jeweiligen Standards hinweggesetzt, was, wie Du schon so treffend bemerktest, nichts über die Sprachdefinition an sich aussagt.

---

Der Versuch, grundsätzliche Schwächen einer Programmiersprache im Nachhinein zu beheben, macht aus ihr keineswegs etwas grundsätzlich anderes. Natürlich stellt es aus meiner Sicht ein erstrebenswertes Ziel dar, dass sich sowohl Compiler-Entwickler, als auch Anwendungsprogrammierer an existierende Standards halten. Das ist aber etwas völlig anderes, als aus einem nicht oder kaum in der Praxis umgesetzten Standard (einer Weiterentwicklung) eine prinzipielle Aussage über eine Programmiersprache zu treffen.

---

Zitat:

---

Wenn man alle Schwächen von Basic behebt, dann noch Deklarationszwang einführt und das Ganze noch um OO etc. erweitert, kommt am Ende eine Sprache heraus, die zwar nicht zu 100% zu Oberon kompatibel ist, aber trotzdem fast genauso aussieht. Warum das dann noch Basic sein soll, nun ja...

---

Zitat:

---

Zitat:

---

Eine Sprache, in der man sich nicht mißverständlich oder gar unsinnig ausdrücken kann, ist eine tote Sprache, weil sie keine Kreativität erlaubt.

---

Mag für menschliche Sprachen gelten. Für Programmiersprachen nicht.

---

was zeigt, daß Du den Sinn nicht verstanden hast. Ohne "Fehler" keine Weiterentwicklung.

--
---

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

Zitat:

---

Original von Holger:

Und so gilt auch für Basic, dass Basic erst einmal die grundlegende Sprache ist, wie sie einst definiert wurde und von fast allen Basic-Dialekten erst mal unterstützt wird. Was darüber hinaus einige Dialekte machen, sagt nichts über Basic aus.

---

Einspruch, Euer Ehren...

Du referierst doch so gern über Standards, dann schau doch mal in den (soweit ich weiß 1991 endgültig festgelegten) ANSI-Standard für BASIC rein. Da findest Du einiges, was Du der Sprache BASIC immer und immer wieder (durch schlichte Weglassung eben dieser Tatsachen) absprichst.

Da wären u.A. zu nennen: Lokale Variablen, Funktionen, Typprüfung und Vorabdeklaration.

Also all das, was nach Deiner Aussage nur "Dialekt-abhängig" ist. Ist es nicht.

Wenn Du allerdings nur das Minimal-ANSI-BASIC betrachtest, hast Du zweifellos Recht. Nur ist da die standardisierte Entwicklung von BASIC halt nicht stehengeblieben, wie Du es immer wieder so gern kolportierst.

Diese Art der Weiterentwicklung hat es übrigens bei nahezu allen Programmiersprachen gegeben und oftmals haben sich Hersteller von Compilern/Interpretern über die jeweiligen Standards hinweggesetzt, was, wie Du schon so treffend bemerktest, nichts über die Sprachdefinition an sich aussagt.

Zum momentanen Thema noch eine sehr persönliche Sicht der Dinge von mir:

Eine Sprache, in der man sich nicht mißverständlich oder gar unsinnig ausdrücken kann, ist eine tote Sprache, weil sie keine Kreativität erlaubt.

Grüße

--
---

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

Zitat:

---

Original von Bluebird:
@whose:im ibrowse ordner unter images/picture , das steht fuer die verschiedenen arten die ein bild haben kann , also laden decodiren fehler usw ...

---

Zitat:

---

ps: achja pointer wars , in dem ganzen urwald im prefs ordner uebersieht man schon einiges oder sieht den wald vor bae umen nicht mehr hehe

---

Grüße
--
---

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

Zitat:

---

Original von Bluebird:
also der rosa ecke icon bei ib ist wohl das selbe , das solte wie ichmeine wohl transparent sein , jedenfals wenn ich die bilder einlade sehen die ecken auch rosa aus , egal ob cgx rechner oder eben das p96 sys

---

Zitat:

---

den maus pfeil konnte man doch editieren ? wenn ich nicht so doof waere wuesste ich auch noch wie aber mir kommts langsam vor viele sachen sind zwar d aber man macht/ nuzt sie so selten da man garnicht mehr weiss wie es geht ...

---

Eigentlich ganz einfach: Prefs/Pointer

Das wird Dir aber nicht viel nützen, da die 3. Farbe des Virge-Hardware-Sprites stets invertierter Hintergrund ist (frag mich aber nicht, wofür das gut sein soll). Von der Sorte Hardware-Sprites gibts bei den älteren GraKas mehrere, die Voodoo soll wohl auch dazugehören (konnte ich aber nicht wirklich definitiv rausfinden).

Übrigens gibt es einen ähnlichen "Transparenz"-Effekt auf z.B. der CVPPC nicht (also nicht wirklich, ich hatte den auch eine Weile auf der Karte, aber das war eindeutig ne Software-Sache. Nach einem letztlich gelungenen Update auf den letzten CGFX-Release ist dieser Effekt nicht mehr vorhanden. Auf der CV64/3D ist das aber immer noch so, unabhängig von der CGFX-Version).

Grüße


--
---

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