Zitat:

---

...auf langwortgröße sollte es schon funtionieren. wer weis wie?

---

code:

---

ValToDez:
	movem.l	d2-d4/a1,-(a7)
	push	a0
	moveq	#4,d1
	move.l	#10000,d3
	moveq	#0,d2
.lp1	moveq	#-1,d4
.2	addq.w	#1,d4
	sub.w	d3,d0
	bpl.s	.2
	add.w	d3,d0
	divu.w	#10,d3
	add.w	#$30,d4
	tst.w	d2
	bne.b	.4
	cmp.b	#"0",d4
	beq.b	.5
	st	d2
.4	move.b	d4,(a0)+
.5	dbf	d1,.lp1
	cmp.l	(a7)+,a0
	bne.b	.pop
	move.b	#"0",(a0)+
.pop	movem.l	(a7)+,d2-d4/a1
	rts

---

code:

---

:
	moveq	#4,d1
	move.l	#10000,d3
in
	moveq	#9,d1
	move.l	#1000000000,d3
ändern.

Und die Instruktionen:
	sub.w	d3,d0
	bpl.s	.2
	add.w	d3,d0
	divu.w	#10,d3
gegen
	sub.l	d3,d0
	bpl.s	.2
	add.l   d3,d0
	divul.l	#10,d3:d3
tauschen.

---

Zitat:

---

Unter MorphOS wird auf den BOM auch verzichtet beim Copy n Paste.

---

Zitat:

---

In diesem Fall ist es ein patch für das input.device.

---

Patch and burn!
Oder anders: Watschen fürs Patchen...
Ich hoffe, nachdem ich jetzt alle Beiträge gelesen habe, dass ihr nichts mehr patchen wollt?

Zitat:

---

NoWinEd interpretiert UTF-8 Codes und konvertiert diese zu ISO-8859-x (ich glaub 1), allerdings sind damit z.B. chinesische Zeichen verloren (durch ? ersetzt).

---

Zitat:

---

Was mir noch einfällt, man könnte durchaus UTF-8 auch tippen, denn man kann ja eine KeyMap machen, die gleich zwei oder drei Zeichen produziert.

---

Zitat:

---

Also wenn TTEngline.library 7.2 gescheit funktioniert, scheint mir das der gangbarste Weg zu sein, einen Texteditor mit Unicode-Fähighkeit auszustatten.

---

Zitat:

---

Ausserdem habe ich die ganzen Texteditor Funktionen schon, fehlt nur das Handling von Mehrbyte Zeichen, bzw. erstmal 16bit chars.

---

Zitat:

---

Keine schlechte Idee. Wenn der Editor allgemein nur 2 Byte Zeichen editieren kann.

---

Zitat:

---

In NTUI ist ein String-Gadget eine einzeilige Textbox mit etwas geänderten Farben und Bordern. Daher kann es automatisch auch Unicode.

---

Zitat:

---

Den Editor würde ich generell nicht auf 16bit umstellen, da sonst schnelles Laden nicht mehr gehen würde, bzw. man hätte grossen Speicherbedarf bei grossen Files. (Ja, bei der Abreit habe ich durchaus mal 1GB grosse Text-Files...).
Aber jede Zeile kann ein Flag besitzen, in welchem Encoding sie vorliegt, und erst beim Speichern wird, nach Bedarf, konvertiert.
Da würde ich 8bit und 16bit unterstützen, später vielleicht UTF-8.

---

Das ist meinem Erachten nach kein günstiger Ansatz da alle Zeichenoperatoren dann für dieses spezielle Format nochmals vorliegen müssen. Einmal als Byte, dann als Wide-Char (16 Bits). Wäre mir persönlich nicht transparent genug.
Zudem denke ich dass bei halbwegs korrekter Implementierung deinerseits Du sowieso nicht um volle 32-Bit Unterstützung herumkommen wirst. Ist aber nur Spekulation meinerseits.


@Thore

Zitat:

---

Wenn der Suchstring auch nach 16Bit konvertiert wird, und bei der Suchfindung auf gerade Adressen geprüft wird, ist die Suche ohne Probleme möglich, wenn der Editor intern auch nur 16Bit Text verwaltet.

---

Pweeh, ich hoffe ich schmeiße nicht alle Beiträge durcheinander - eurer Thread ist ein wenig lang und ich hatte keine Zeit in den letzten Tagen zu antworten.

Was erwartest Du auf ungeraden Adressen zu finden wenn das Format als 16-Bit ausgelegt ist?
Alle Code Points sind bei einem 16-Bit Format 'Words', d.h. sie sollten sowieso auf geraden Adressen liegen. 16-Bit ('Words') bedeutet aber nicht, das ein Zeichen aus einem einzelnen 'Word' besteht, es sei denn man beschränkt sich auf Unicode 3.
Habe ich hier was nicht verstanden? Aufklärung bitte!


@Wanderer

Zitat:

---

Für das Casing gibt es unter Unicode.org Listen, die man verwenden kann. Sollte kein Problem sein, so gross sind die Listen nicht, was sind schon ein paar 1000 Einträge?

---

Autsch.
Die Basis-Datei für Unicode 5.1 ist eine Textdatei die schon mal 1 Mbyte groß ist. Alle Basisinformationen, die durch diese Datei beschrieben werden, in ein maschinenlesbares Format umzusetzen ohne irgendwelche Kniffe anzuwenden, wird in einer Tabelle zwischen 3 und 4 Mbytes resultieren, je nachdem welche Informationen abgedeckt werden sollen.


@Thore

Zitat:

---

Großbuchstabe + 0x20 = Kleinbuchstabe. Das ist auch bei den Unicode-Zeichen so. Allerdings muss man die Grenzen wissen, da die meisten Zeichen keine Groß-/Kleinschreibung haben.

---

Zitat:

---

Am besten suchst Du in unicode.org nach JOHAB.TXT, da hats ziemlich viele drin.

---

Nee, nix da. UnicodeData.txt ist euer Freund.


@Wanderer

Zitat:

---

Wie Thor schon geschrieben hat, haben die meisten Zeichen keine verschiednene Casings. Deshalb ist die Liste viel kleiner.

---

Zitat:

---

je nach lib, muss man sich fast so lange damit rumschlagen bis es läuft, als wenn man es selbst implementiert.

---

Zitat:

---

Die Ausnahmen von 0x20-Sprung sind nicht so viele wie Du annimmst, man findet sie in ISO-8859-10.

---

Zitat:

---

Es sind auch keine 100000 Zeichen im 2 Byte Unicode sondern nur 65536 (die nicht darstellbaren mitgerechnet).

---

Zitat:

---

Mit Capital Zeichen meine ich "große Buchstaben, zu denen ein Kleinbuchstabe gehört", also die Zahlen doppelt nehmen, also schätzungsweise 300 Groß + Kleinzeichen

---

Zitat:

---

Mir geht es hierbei mehr draum, mit Unicode Files überhaupt was anfangen zu können und sie editieren zu können ohne das Dokument zu zerstören. Alle Feinheiten der Anzeige muss man nicht unbedingt haben, weil, wie gesagt, es wenig Leute auf dem Amiga betreffen würde.

---

Zitat:

---

Für Darstellung auf einer Website gebe ich dir aber recht, denn da will man ja einen Text schön formatiert lesen. Bei Editoren ist es manchmal sogar umgekehrt, dass man z.B. Non-Spacing Marks seperat hat um sie besser identifizieren/editieren zu können.

Zitat:

---

Fürs Editieren ist es sogar besser die Marks explizit zu sehen.

---

---

Oje, da sind wir beide aber grundsätzlich verschiedener Meinung.
Gerade komplexe Schriftbilder sind darauf angewiesen, dass die Non-Spacing-Marks auf die korrekten Positionen ausgerichtet werden ansonsten wird es unleserlich, nicht für Dich und mich, aber für die Menschen die diese Sprache beherrschen.

Zitat:

---

Es geht hier ja auch nicht darum, ein spezial Tool zum Anzeigen von jeder erdenklichen Unicode File zu machen, sondern um einen Texteditor, der das momentan gar nicht kann, zu erweitern dass eine Unicode File korrekt bearbeitet werden kann.

---

Zitat:

---

Mir gefällt aber die Idee von Holger gar nicht schlecht, die Unicode Zeichen vorzurendern und als Bitmaps dem Editor beizulegen. Den Text() Befehl zu simulieren ist ja dann trivial.

---

Zitat:

---

Mir geht es darum, Text files (oder auch Binaries) verlustfrei im Texteditor zu editieren und wieder zu speichern, dann spart man sich auch ab und an den Hex Editor anzusmeissen.

---

Zitat:

---

Weiss jemand, ob es zur freetype2.library irgendwo ein SDK oder zumindsest eine .fd File gibt?

---

Zitat:

---

Die ttengine.library scheint mir von allen wohl am geeignetsten zu sein. Die hatte ich auch schonmal in TuiTED integriert, allerdings gab es Probleme mit dem Layout. Mal sehen ob ich es diesmal besser hinbekomme.
Wird dann allerdings nicht TuiTED werden, sondern das NTUI TextBox Widget.

Zitat:

---

@Thore
Die TTEngine.library ist ein guter Ansatz, jedoch ist mir noch kein Programm bekannt, das auch Copy n Paste unterstützt. Vielleicht lassen sich die relevanten Routinen (u.a. OpenFont()/CloseFont(), Text(), TextLength() und TextExtend()) durch die TT_ Funktionen patchen, nur muss hierfür geprüft werden, ob ein TTF-Font benutzt wird oder ein anderer, und je nach dem zwischen den alten Routinen und den TT-Routinen umschalten muss. Wenns denn überhaupt so machbar ist...

---

---

Zitat:

---

Ich dachte MOS macht das lediglich via TTEngine, was ja aber nicht direkt OS Funktionen sind und auch angeblich Probleme hat wenn zwei Programme die Lib gleichzeitig nutzen.

---

Zitat:

---

Mit dem Clipboard ist es natürlich etwas schwierig. Hier würde sich evtl. utf-8 anbieten, wie für alle OS funktionen, dann bräuchte man keine extra Funktion. Allerdings müssten die Funktionen irgendwie wissen, dass es utf-8 ist, und nicht ISO-xzy etc.
Evtl. wäre das ein Fall für die locale.library?

---

Zitat:

---

@Holger

Trotzdem wird dann das momentan aktive Fenster deaktiviert.

---

Zitat:

---

Ja. Egal ob man den Zeiger innerhalb der Layer-Struktur ändert, die Layer-Struktur bleibt intakt und die Graphics- bzw. die Layer-Bibliothek kann den Refresh ausführen. Intuition ist nicht zuständig für die Erneuerung von Layern - sie kann es nur veranlassen bzw. hinauszögern.

@Holger

Zitat:

---

Das klingt für mich zu vereinfacht. Intuition sendet Refresh-Nachrichten an Anwendungen. Dazu muss intuition entweder über die Fenster iterieren und deren Layer auf gesetztes Damage-Bit überprüfen, [...].

---

---

Zitat:

---

Anbei, bitte nicht IDCMP_INACTIVEWINDOW oder IDCMP_ACTIVEWINDOW spezifizieren falls ein und derselbe MsgPort für das Hauptfenster und die Kindfenster verwendetet wird, ansonsten ist aus ersichtlichen Gründen ein Systemabsturz nicht fern!

Zitat:

---

Holger
Das ist für mich überhaupt nicht ersichtlich.

---

---

Nehme an Du hast zehn Kindfenster geöffnet – dementsprechend bekommt Du laufend MOUSEMOVE-Nachrichten.
Kommt jetzt ein INACTIVWINDOW schließt Du ein oder alle Kindfenster. Nichtsdestotrotz bekommst Du noch die Koordinaten (MOUSEMOVE) nachgereicht, die zum geschlossenen Kindfenster gehören.
Falls Du hier, genauso wie ich ( ), keine sonderliche Sorgfalt walten lässt, wirst Du genau wie ich ( ), einen Systemabsturz erleben, da Du wohlmöglich nach wie vor eine grafische Operation in einem nicht mehr existenten Objekt durchführen willst, da Du ja die Koordinaten und die Aufforderung zum Zeichnen dazu erhalten hast...

Ich hab’ die obere Erklärung abgegeben, weil ich zu diesem Zeitpunkt noch den Quellcode zum Beispiel mitliefern wollte, mich dann aber anders entschlossen habe. Dementsprechend war die Erklärung auf das nicht mitgelieferte Beispiel gemünzt.
'Tschuldigung.

Zitat:

---

@whose
Aber mal eine andere Frage: Kann man sich den MessagePort für das Kind-Fenster nicht im Grunde sparen? Oder gibt es Fälle, in denen der tatsächlich sinnvoll wäre?

---

Ja, habe ich ja auch so programmiert.
Und zu zwei: Mir fällt auf die Schnelle kein Fall ein wo es sinnvoll wäre.

Zitat:

---

@Holger

Entscheidend ist, dass graphics/layers lediglich Damage-Bits auf den Layern setzen und sonst gar nichts weiter tun. Nur intuition weiß, wann diese Bit überprüft werden müssen, nämlich nach jeder Window resize/move/stacking Operation, bzw. jeder anderen Operation, die die Layer verändern kann.

Deshalb darf keine Anwendung die Layer direkt manipulieren, sondern ausschließlich intuition-Funktionen benutzen.

---

Zitat:

---

@Holger

Was ist eigentlich mit dem selten benutzten Feature der "Requester"?

---

Zitat:

---

@Holger

...gäbe es gar keinen Grund, Hacks zu benutzen...

---

Zitat:

---

@Der_Wanderer

Ich dachte nur, vielleicht kann ich das alles direkt im Kind-Fenster emfangen, dann gibt es keine Doppeldeutigkeit, was mit dem Klick gemeint ist. Der klick kann ja auch bedueten, dass ich ein Gadget im Elternfesnter betätigen will.

---

Nö, wennste ( bin Niederrheiner, wir sprechen so ) schon den Zeiger für den Eingabestrom Deines Kindfensters auf Dein Hauptfenster "verbiegst", kriegtste ( ) auch die die Nachricht dort, wo der verbogene Zeiger hinzeigt; sprich Dein Hauptfenster.

Allerdings existiert eine elegante Methode, um herauszufinden, ob nun irgendein Mausklick Dein Hauptfenster tangiert oder eines Deiner Kindfenster. Diesen Vorgang beschreibe ich weiter unten.

Zitat:

---

@Der_Wanderer

Solange muss halt das Elternfenster Disabled sein, was aber ja auch ok ist.

---

Zitat:

---

@Der_Wanderer

Diese Technik bräuchte man für sämtliche Gadgets oder Menus, die über das Elternfenster hinausladen können, also z.B. für den Start Button eines Startmenu's oder andere PopUp Menus, Drop-Down Listen etc.

---

Zitat:

---

@Der_Wanderer

Ich frage mich nur wie "legal" (und somit Kompatibel) das verbiegen des Window Pointers ist, oder ob man das schon als "Hack" werten muss.

---

Es ist die einzige mir bekannte Maßnahme um ein SuperBitMap-Layer mit einem Fenster zu koppeln. Dies ist auch so offiziell von Commodore Amiga publiziert worden, dementsprechend ist es kein Hack.
Allerdings erstellt man hierbei die Zeichenfläche (Bitmap und Layer) von Hand und erst dann setzt man den Zeiger in der Layer-Struktur auf ein geöffnetes Fenster.
Es ist auch nicht so, dass man den Window-Zeiger verbiegt, sondern nur in die Layer-Struktur das Empfangsfensters einträgt, im Falle dass der freche Nutzer die Maus zum Linksklicken benutzt und somit Intuition einen Anhaltspunkt hat, welche Zeichenfläche betroffen ist und ob der freche Nutzer unter Umständen eine andere Zeichenfläche nutzen möchte, d.h. er möchte ein anderes Fenster zur Eingabe auswählen und somit aktivieren.
Die Window-Struktur ist *das* Bindeglied zwischen dem Input-Task und den einzelnen Zeichenflächen, mehr nicht.
Layers sind die eigentlichen Grundgerüste für das, was wir Fenster nennen. Aber, vor lauter Fenstern sieht man die Layers nicht!

Zitat:

---

@Holger

Dann kannst Du aber nicht verhindern, dass das Elternfenster deaktiviert wird.

---

Zitat:

---

@Holger

Aber ob das mit dem Refresh auch noch korrekt funktioniert?

---

Ja. Egal ob man den Zeiger innerhalb der Layer-Struktur ändert, die Layer-Struktur bleibt intakt und die Graphics- bzw. die Layer-Bibliothek kann den Refresh ausführen. Intuition ist nicht zuständig für die Erneuerung von Layern - sie kann es nur veranlassen bzw. hinauszögern.
Ist leider ein zu komplexes Thema als dass ich es in ein paar Zeilen abhandeln könnte.


Jetzt mal ein konkretes Beispiel:
Man öffnet ein Fenster ganz gewöhnlich mit all seinen speziellen Eigenschaften und den IDCMP-Flaggen, die Benachrichtigungen auslösen sollen. Dementsprechend haben wir unser Hauptfenster.

Nun öffnet man das Kindfenster, mit oder ohne irgendwelche Angaben von IDCMP-Flaggen; ist eigentlich egal. Bei Angaben von IDCMP-Flaggen, die so nicht im Hauptfenster vorhanden sind, muss natürlich das Hauptfenster mittels ModifyIDCMP() mitgeteilt werden, dass auch andere als die ursprünglich spezifizierten Flaggen eine Benachrichtigung auslösen sollen.
Anbei, bitte nicht IDCMP_INACTIVEWINDOW oder IDCMP_ACTIVEWINDOW spezifizieren falls ein und derselbe MsgPort für das Hauptfenster und die Kindfenster verwendetet wird, ansonsten ist aus ersichtlichen Gründen ein Systemabsturz nicht fern!

Bei der Initialisierung der Fensterbeschreibung (z.B. OpenWindowTagList()) wird eine Aktivierung des Fensters unterbunden (mittels "WA_Activate, FALSE"). Ansonsten deaktivieren wir beim Öffnen des Kindfensters das Hauptfenster... Ist wohl nicht gewollt.

Falls das Öffnen klappte, haben wir ein Fenster, welches bei Angaben ohne IDCMPs (siehe oben) *keinen* eigenen MsgPort besitzt.
Also erlauben wir dem Kindfenster den MsgPort des Hauptfensters zu benutzen:

C code:

---

if (Kindfenster->UserPort == NULL)
    Kindfenster->UserPort = Hauptfenster->UserPort;

---

C code:

---

Kindfenster->WLayer->Window = Hauptfenster;

---

C code:

---

struct InutiMessage *msg;
LONG x, y;            /* Muss mit Vorzeichen arbeiten (speziell für OS1.x) */
struct Layer *welches;

msg = (struct IntuiMessage *) GetMsg( Hauptfenster->UserPort);
if (msg)
{
    if (msg->Class == IDCMP_MOUSEMOVE)
    {
        x = (LONG) msg->MouseX;
        y = (LONG) msg->MouseY;
        /* x,y relativ zur linken, oberen Ecke des Hauptfensters */

        x += Hauptfenster->LeftEdge;
        y += Hauptfenster->TopEdge;
        /* x,y absolut im Display */

        /* Nun, welches Layer liegt unterhalb des Mauszeigers? */
        welches = WhichLayer( Hauptfenster->WLayer->LayerInfo, x, y);
        if (welches)
        {
            /* Berechne relative Koordinate für das betreffende Layer */
            x -= (LONG) welches->bounds.MinX;
            y -= (LONG) welches->bounds.MinY;
            /* "bounds" ist eine Struktur innerhalb der Layer-Struktur,
               die den Ursprung des Layers im Display beschreibt sowie
               dessen Ausmaße. */
        }
        else
        {
            x = 0;
            y = 0;
        }
    }

    if (msg->Class == IDCMP_MOUSEBUTTONS)
    {
    /* Watt tun bei 'nem Klick? ( ;-) ) */
    }
}

---

C code:

---

void SchließeKindFenster( struct Window *kindFenster, struct Window *hauptFenster)
{
    struct Message *msg;

    Forbid();

    /* Teilen wir uns einen MessagePort mit dem Hauptfenster? */
    if (kindFenster->UserPort == hauptFenster->UserPort)
    {
        kindFenster->UserPort = NULL;    /* Extrem wichtig - ansonsten gibt
                                            CloseWindow( HauptFenster) den MsgPort
                                            ein zweites Mal frei --- CRASH! */
    }
    else
    {
        /* Haben eigenen Port... */

        while ( (msg = (struct Message *) GetMsg( kindFenster->UserPort)) )
            ReplyMsg( msg);
        ModifyIDCMP( kindFenster, 0)
    }

    /* Man könnte noch ein:
    kindFenster->WLayer->Window = kindFenster;
       einbauen, muss man aber nicht. Es werden ja keine Nachrichten mehr empfangen. */

    Permit();

    CloseWindow( kindFenster);
}

---

Das war's.


Habe eine Testdatei hochgeladen: ContextMenus.lha


Grüße


--
Stupid mistakes are always made by others -
we only make unavoidable errors

Zitat:

---

Original von Der_Wanderer:
Aber geht das nun was ich vorhabe oder nicht?

---

Zitat:

---

Original von Der_Wanderer:

Das Fenser empfaengt dann aber keine IDCMP Messages, hab ich recht?

---

Zitat:

---

Das geht nur, wenn es aktiv ist, oder?

---

Hat mit Aktivierung eines Layers nichts zu tun. Im Prinzip gibt es nämlich keine aktiven Layers sondern nur aktive Fenster. Layer = Grafik, Window = Input.
Ein Layer ist nichts anderes als ein Teil einer BitMap (Screen) oder die Zeichenfläche einer ganzen BitMap (SuperBitMap-Layer), aber immer ausschließlich eine Zeichenfläche. Intuition dockt seine Windows-Struktur an eine vorhandene Layer-Struktur an, damit Intuition ermitteln kann, welchem Programm (Message-Port) es eine Nachricht zukommen lassen muss, falls ein Ereignis auftaucht. Dazu geht Intuition davon aus, dass das Layer, welches das aktive Fenster repräsentiert, die Ereignisse erhalten soll.

Nachtrag:
Layers sind Lösungen um mehreren gleichzeitig laufenden Programmen exklusive Zeichenflächen zu bieten, ohne dass sich der Programmierer um die Bereichsgrenzen kümmern müsste, d.h. dass er nicht unabsichtlich fremde Zeichenbereiche überschreibt/übermalt, aber Layers haben rein gar nichts mit Ereignissen zu tun. Layers werden von Intuition nur "vergewaltigt", damit Intuition cleverer erscheint als es ist.


Gruß

--
Stupid mistakes are always made by others -
we only make unavoidable errors

Zitat:

---

Original von Der_Wanderer:
Hallo!

Kann ich irgendwie verhindern, dass mein Fenster aktiv wird, wenn der User mit der Maus hineinklickt?

Beim Amistart ist das so, muss also irgendwie gehen.

---

Zitat:

---

Es gibt viele mögliche Fehlerquellen.

---

Zitat:

---

Auch, wenn Du das bereits korrigiert hast, bleibt ja immer noch der Fakt, dass Deine Daten von Dir mit demselben Timing generiert werden, mit dem Du hinterher liest, während der echte Parallelport vom Timing des Lesens unabhängig funktioniert [...]

---

Zitat:

---

[...] wenn man z.B. die Ressource nicht korrekt gelockt hat

---

Zitat:

---

Was glaubst Du?!?!? Ich bin kein Hellseher.

Zitat:

---

der code steht doch oben:

code:

---

junk&=SetIRQAttrI&(ihandle&,4)

---

das war doch was du meinst?

---

---

Zitat:

---

Ja, mach das. Dann habe ich zumindest einen Anhaltspunkt.

Zitat:

---

Hab deine Email Adresse aber nicht...

---

---

Zitat:

---

Die Funktion TIMER ist mehr als ungenau.

Zitat:

---

Das muss an WinUAE liegen.

---

---

Zitat:

---

Ja, ist halt so eine sache mit UAE<->Amiga was auf dem einen läuft tuts manchal nicht auf dem anderen.

---

Zitat:

---

Leider wurden hier auf meiner Maschine Abschnitte doppelt wiedergegeben [...]

Zitat:

---

Du hast doch nur UAE oder?

---

---

Zitat:

---

Hast Du das normale Signal-Handling abgeschaltet? - Dann kann es nicht funktionieren.

Zitat:

---

Ich glaub schon.

---

---

Zitat:

---

Wie oft pro Sekunde kommen diese vor (schätzungsweise)?

Zitat:

---

5 mal vielleicht. Das variiert. Ich kann dir eine Datei auch Mailen.

---

---

Zitat:

---

t! = TIMER-t! REM --- Und Ende festhalten (TIMER ist seeeehr ungenau:
REM --- bei 200004 Bytes 13,76 Sek. mit Stoppuhr aber 16,18 Sek. laut TIMER)!

Zitat:

---

Bei mir sinds 10.1x Sek.

---

---

Zitat:

---

Hier funktioniert es.

Zitat:

---

Ja, funktioniert, leider nur so wie meins. Also mit Knackser.

---

---

Zitat:

---

Hat das ASM Beispiel und das C-Beispiel doch auch nicht, solange man den Puffer so lässt wie er ist.

---

Zitat:

---

Nur wenn Deine Routine innerhalb des Interrupt aufgerufen wird (usersCode, usersData). Ansonsten, wenn's auf Prozess-Ebene läuft, nicht.

Zitat:

---

Ja, dachte ich mir auch so, geht aber nicht.

---

---

Zitat:

---

Ja, wie ich sagte es gibt diese (Intensiv) Knackser mit aktiver und deaktiver Audio-Ausgabe.

---

Zitat:

---

Hört sich aber so gut an wie Multimon bis auf die (kleinen) Knackser.

---

Zitat:

---

Jetzt geht die Monitorausgabe nicht mehr...

---

code:

---

REM  Zwei Macken sind mir in MBasic aufgefallen:
REM  Umlaute mag es gar nicht und CALL funktioniert nicht so wie in AmigaBasic

    REM ON BREAK GOTO FastOut
    REM BREAK ON

    LIBRARY "exec.library"
    DECLARE FUNCTION AllocVec&() LIBRARY
    DECLARE FUNCTION FreeVec&() LIBRARY
    DECLARE FUNCTION xWait&() LIBRARY

    LIBRARY "dos.library"
    DECLARE FUNCTION xOpen&() LIBRARY
    DECLARE FUNCTION xWrite&() LIBRARY
    DECLARE FUNCTION xClose&() LIBRARY
    DECLARE FUNCTION Delay&() LIBRARY

    LIBRARY "ire.library"
    DECLARE FUNCTION InitIRQ&() LIBRARY
    DECLARE FUNCTION StartIRQ&() LIBRARY
    DECLARE FUNCTION DeleteIRQ&() LIBRARY
    DECLARE FUNCTION GetIRQAttrI&() LIBRARY
    DECLARE FUNCTION SetIRQAttrI&() LIBRARY

    LIBRARY OPEN "exec.library"
    LIBRARY OPEN "dos.library"
    LIBRARY OPEN "ire.library"


    CONST PGROESSE& = 40000    REM --- Puffergroesse
    CONST Hz&       = 14880    REM --- Frequenz


    CONST MEMF_CLEAR& = 65536

    CONST MODE_NEWFILE&     = 1006
    CONST SIGBREAKF_CTRL_C& = 4096


    CONST THIS_SIGBIT_DBUF_FULL& = 1
    CONST THIS_DBUF_FULL&        = 16
    CONST THIS_IRQ_SIGBIT&       = 2
    CONST DISABLE_SIGNALLING&    = 4
    CONST ENABLE_SIGNALLING&     = 8
    CONST THIS_FREQUENCY&        = 32
    CONST THIS_PERIOD&           = 256
    CONST THIS_SAMPLE_POS&       = 1024
    CONST TOGGLE_DMA_ACCESS&     = 64
    CONST TOGGLE_MAKE_AUDIBLE&   = 128
    CONST TOGGLE_16BIT&          = 512


    REM $NOEVENT
    REM $NOOVERFLOW
    REM $NOLINES


    REM --- Los geht's
    REM POKEB &hBFD000,2    --- Paper Out signalisieren
    POKEB &hBFE301,0     REM --- Parallel-Port auf Eingang

    Index& = 0    REM --- Dateinamenerweiterung

    MySample1& = AllocVec&( PGROESSE&, MEMF_CLEAR&)
    MySample2& = AllocVec&( PGROESSE&, MEMF_CLEAR&)
    IF MySample1& <> 0 AND MySample2& <> 0 THEN

        DIM pufferliste&(12)
        pufferliste&(0) = MySample1&
        pufferliste&(1) = MySample2&
        pufferliste&(2) = 0

        REM --- Interrupt und benötigte Strukturen initialisieren
        ihandle& = InitIRQ&( Hz&, SADD("MBasic Digitizer"+CHR$(0)), 0, 0, VARPTR( pufferliste&(0) ), PGROESSE&)

        IF ihandle& <> 0 THEN
            REM --- Signal-Bit für "Puffer-Ist-Voll" holen und in Maske wandeln
            sigmask& = ( 1 << GetIRQAttrI&( ihandle&, THIS_SIGBIT_DBUF_FULL&) )

            REM --- Normales Interrupt-Signal-Handling ausschalten
            junk& = SetIRQAttrI&( ihandle&, DISABLE_SIGNALLING&)

            REM --- Audio-Ausgabe aus/anschalten
            REM junk& = SetIRQAttrI&( ihandle&, TOGGLE_MAKE_AUDIBLE&)

            REM --- DMA Audio-Ausgabe einschalten
            junk& = SetIRQAttrI&( ihandle&, TOGGLE_DMA_ACCESS&)


            junk& = Delay&( 50)    REM --- 1 Sekunde warten


            REM --- Interrupt starten
            junk& = StartIRQ&( ihandle&)

            DO
                PRINT "Starte Timer..."
                t! = TIMER    REM --- Zeit des Starts festhalten

                REM --- Warten bis irgendetwas passiert...
                received& = xWait&( sigmask& OR SIGBREAKF_CTRL_C&)

                IF received& AND SIGBREAKF_CTRL_C& THEN
                    EXIT LOOP
                ELSE
                    t! = TIMER-t!    REM --- Und Ende festhalten (TIMER ist seeeehr ungenau:
                    REM --- bei 200004 Bytes 13,76 Sek. mit Stoppuhr aber 16,18 Sek. laut TIMER)!

                    CALL WriteBuffer( GetIRQAttrI&( ihandle&, THIS_DBUF_FULL&), PGROESSE&)

                    REM --- Benötigte Zeit wiedergeben
                    PRINT PGROESSE& "Bytes wurden innerhalb von" t! "Sekunden mit";
                    PRINT GetIRQAttrI&( ihandle&, THIS_FREQUENCY&) "Hz digitalisiert."
                    PRINT "Diese Angabe ist mit Vorsicht zu genießen!"
                END IF
            LOOP

            REM --- Interrupt beenden und Ressourcen freigeben
       FastOut:
            junk& = DeleteIRQ&( ihandle&)
       END IF


    END IF

    IF MySample2& <> 0 THEN
       REM --- Puffer freigeben
       junk& = FreeVec&( MySample2&)
    END IF

    IF MySample1& <> 0 THEN
       REM --- Puffer freigeben
       junk& = FreeVec&( MySample1&)
    END IF


    REM --- Alle geoeffneten Bibliotheken schliessen
    LIBRARY CLOSE

    END
    REM ---- PROGRAMMENDE ----



    REM --- Pufferinhalt als Datei schreiben.
    SUB WriteBuffer( adr&, xlen&)
    fh& = xOpen&( SADD("RAM:sample_raw"+STR$(Index&)+CHR$(0)), MODE_NEWFILE&)
    IF fh& <> 0 THEN
        junk& = xWrite&( fh&, adr&, xlen&)
        junk& = xClose&( fh&)
    END IF

    Index& = Index& + 1

    END SUB

---

Zitat:

---

[...] wie willst Du dann von Basic aus vorgehen?

Zitat:

---

Einfach einen Wert nehmen der grade Teilbar ist.

---

---

Zitat:

---

Das dürfte normal sein - das Timining-Verhalten ist bei DMA-freier Wiedergabe was gänzlich anderes als mit DMA.

Zitat:

---

Warum eigentlich ohne DMA? Besser als das ASM beispiel und hört es sich nicht an.
Das Timing war doch ohnehin exakt.

---

---

Zitat:

---

Heißt das, dass Deine eigenen Routinen zum Digitalisieren diese Knackser beinhalten und TimerIRQ solche Mätzchen nicht macht?

Zitat:

---

Ich glaube schon. Muss ich bei der Lib verwendung ohne eigenen Code etwa die Register sichern?

---

---

Zitat:

---

Das Timing wurde komplett geändert.

Zitat:

---

Habe ich jetzt beim Infrarot-Senden eine Abweichung dadurch?

---

---

Zitat:

---

Es wäre nett, wenn Du mir sagen könntest, ob mittels Digi digitalisierte Dateien und mittels SampleEngine wiedergegebene Dateien korrekt sind - d.h. ob keine Fehler (Blips) darin enthalten sind.

Zitat:

---

Also bei Basic keine änderung. Ja, Fehler sind relativ.
Kleine störungen sind noch drin, also nicht so gut wie mit dem ASM-Beispiel. Samplemanager sagt was von über 14000 "crackles" wobei das sehr relativ zu sehen ist.

---

---

Zitat:

---

Ja, aber man könnte dem mit einigem Aufwand entgegentreten - ich persönlich kann aber mit diesen kurzen Blips gut leben, da diese ja nicht als Daten in die FAST-RAM Puffer übernommen werden.

Zitat:

---

Na wenn ich die Audio-Ausgabe selbst machen kann und das nicht in den Puffer geschrieben wird, bekomme ich das auch
irgendwie in den griff.

---

---

Zitat:

---

Der Digitizer-Code funktioniert - und schmiert nicht ab?

Zitat:

---

Jetzt soweit ja, ins Array Poke't man nicht, da nimmt man =.
Poken macht man dann bei AllocVec bereich.

---

---

Zitat:

---

Sag mir mal ob jetzt die Audio-Ausgabe ansatzweise in Ordnung ist.

Zitat:

---

Das schnarren ist weg, aber jetzt hört sich es bei 22050 etwa so an wie bei 14000 HZ. Also nicht in der Geschwindigkeit sondern in der Qualität.

---

---

Zitat:

---

Ja, per MBasic habe ich diese Knackser die voll in den -127er bereich gehen. Das ist im Puffer(Audioausgabe aus) und bei der Aktiven Audioausgabe so. Beim beiligenden Tool hab ich das nicht mehr vernommen.

---

Heißt das, dass Deine eigenen Routinen zum Digitalisieren diese Knackser beinhalten und TimerIRQ solche Mätzchen nicht macht?


Habe jetzt so was wie die endgültige Fassung der Bibliothek fertig gestellt.

Das Timing wurde komplett geändert. Es basiert nicht mehr auf 60 Hz Netzspannungen... War ein Fehler zur Berechnung der Periode (Audio-Ausgabe). Jetzt wird die Periode anhand der Frequenz berechnet und danach die Frequenz anhand der Periode. Danach wird aufgrund der neu berechneten Frequenz einer der beiden CIA-A Timer mit dem korrekten Wert initialisiert.

Beispiel: Falls Du 14880 Hz als "callsPerSecond" spezifizierst, wird stattdessen eine Frequenz von 14840 verwandt.
Du kannst das abfragen, indem Du GetIRQAttrI( 32) aufrufst.
Um die Periode zu ermitteln, kannst Du GetIRQAttrI( 256) verwenden.

Als nächstes habe ich die DMA-freie Audio-Ausgabe überarbeitet: Das INTEN-Bit im Interrupt-Kontrollregister wird jetzt immer gelöscht - damit man DMA-freie und DMA-unterstützende Ausgabe während der Audio-Wiedergabe wechseln kann. Hoffentlich hat das keine negativen Seiteneffekte auf den Blitter/Copper…
Das Programm Digi wechselt alle 5 Sekunden den Modus während es digitalisiert.

Voreingestellt ist jetzt der Typ DMA-freie Audio-Ausgabe. Falls Du das nicht willst, musst Du SetIRQAttrI( 64) einmalig aufrufen.

Das Programm Digi digitalisiert wirklich - es schreibt Dateien mit maximal 540000 Bytes in die RAM-Disk - allerdings kann eine einzige Audio-Ausgabe aus mehreren solcher Dateien bestehen. CTRL-C beendet es wie gewohnt.

Habe das Programm SampleEngine beigefügt (dafür muss die noise.library ins LIBS-Verzeichnis), mit dem Du diese Dateien abspielen kannst. Ist allerdings ein Uralt-Tool - könnte ein paar Macken haben. Eine ist z.B. dass die einzuladende Datei komplett ins CHIP-RAM passen muss - ich hoffe Du hast 1 bis 2 MBytes CHIP-RAM?
Wenn keine Audio-Ausgabe erfolgt, kann das an einem Bug im Programm liegen. Einfach solange den Play Button betätigen bis es geht (evt. solange warten, bis der Warten-Mauszeiger verschwindet).

Mit diesem Programm kannst Du verifizieren, dass die Audio-Ausgabe mehr oder weniger unabhängig von dem Digitalisieren ist, was bedeutet, das selbst eine inkorrekte Audio-Ausgabe nicht gleichzusetzen ist mit einer inkorrekten Digitalisierung. Probiere es mal aus - dann verstehst Du was ich meine.

Anbei, DMA-unterstützende Audio-Wiedergabe (also mittels CHIP-RAM Puffer) sollte jetzt seltener einen Abschnitt doppelt wiedergeben - bedingt durch die korrekte 50 Hz Initialisierung.

Ach ja, und zu guter Letzt: Cause() kann doch nicht beliebig oft innerhalb einer Sekunde aufgerufen werden.

Es wäre nett, wenn Du mir sagen könntest, ob mittels Digi digitalisierte Dateien und mittels SampleEngine wiedergegebene Dateien korrekt sind - d.h. ob keine Fehler (Blips) darin enthalten sind.


Gruß

Zitat:

---

Bei nur 500 MHz würde ich Amithlon empfehlen.

Zitat:

---

Das kostet doch Geld und hat keine Custom Chip Emu?

---

---

Zitat:

---

Meines Wissens nach spielt es keine Rolle beim Lesen von Daten die an der parallelen Schnittstelle anliegen, ob Eingang oder Ausgang spezifiziert wurde; es wird immer der aktuelle Wert der anliegt, zurückgegeben.

Falls ich mich täusche berichtige ich das im Programm-Code.

Zitat:

---

Am besten ist gar nicht schalten, das kann ich ja in mein Prog machen und L/R wähle ich ja auch selbst.

---

---

Zitat:

---

Du meinst anstelle des CIA-A Interrupts einen CIA-B?

Zitat:

---

Ähm, so wie es im ASM-Beispiel ist.

---

---

Zitat:

---

Also das "kleine" Kacken, vermute ich kommt daher das der CIA-Counter nicht Syncron mit der Wiedergabe läuft.
Man macht ja eine User angabe z.B. 22050 Hz, nun ist das mit den 709379 nicht grade zu Teilen -> abweichung von 0.17138322.

---

Zitat:

---

Und ja, falls eine Pufferliste spezifiziert wird, also nicht NULL ist, wird die Audio-Hardware in Gang gesetzt.

Zitat:

---

Benutzt aber Random-Speicherbereiche. Nach einem Neustart spielte es noch daten die vom voherigen Versuch waren

---

---

Zitat:

---

Falls Du das nicht wünscht, kann ich das ausbauen.

Zitat:

---

Ich denke mal, dies ist vom Hauptprogramm sinnvoller.
Sonst wäre es ja nicht so sinnvoll das das Programm die Puffer zur verfügung stellt.

---

---

Zitat:

---

Tut mir leid, dass Du das Versuchskaninchen spielen musst -

Zitat:

---

Das ist absolut kein Problem, ich bin sehr froh das du mir bei diesem Timing Problem hilfst...

---

---

Zitat:

---

Wenn's leiert oder blechern klingt baue ich das wieder raus.

Zitat:

---

Leiern und blechern nicht, aber da sind massive Störungen drauf.
Wie soll ich die beschreiben, brummen, schnarren?

---

---

Das habe ich befürchtet - Mist!

Komisch, nachdem ich alle Preprozessor-Kommandos durch Laufzeitvariabeln ersetzt habe, lief es plötzlich auch hier. Nach mehreren Tests hat sich herausgestellt, dass im Falle einer Veränderung am Inhalt des Audio-Puffers (CHIP-RAM), der ja eigentlich bei der Verwendung der Audio-Hardware ohne DMA, dass heißt Speicherzugriffe durch die Custom-Chips, keinerlei Bedeutung hat, diese Veränderung am Pufferinhalt von der Audio-Hardware registriert und in irgendeiner Weise mit negative Folgen quittiert wird. Hmmm, nachdem der CHIP-RAM Puffer nicht mehr verändert wird, kann selbst unter WinUAE DMA-freie Audio-Ausgabe erzeugt werden.
Kann mir jemand dieses Verhalten erklären?

Um noch einen drauf zu setzen:
Cause() kann beliebig oft innerhalb einer Sekunde aufgerufen werden. Meine Spekulation bezüglich des Timings ist vollkommen falsch. Dies bedeutet im Umkehrschluss, dass es mittels des Timer-Device theoretisch möglich sein sollte, zigtausend Prozessor-Unterbrechungen pro Sekunde zu generieren. Auch unter MorphOS/OS4!
Dementsprechend brauch man/frau keine CIAs.
Kann aber noch nicht sagen, welche Voraussetzungen für das Timer-Device geschaffen werden müssen um das zu erreichen (doppelte Interrupt-Struktur?).

Zitat:

---

Probiere mal TimerIRQ() - wenn's damit klappt, ist dein Basic-Programm für die Hits verantwortlich (falsche Parameter?).

Zitat:

---

Ja, sag mir gleich nochmal, die Puffer, benötigst du da einen Pointer auf einen Pointer der auf den Allocierten
Speicher Zeigt?
Ich hab jetzt nur den Pointer in der Pufferliste geschrieben welcher von AllocVec kommt.
Und Fast-Mem ist richtig?

---

---

code:

---

__________1. Langwort  2. Langwort  3. Langwort  4. Langwort
00000BB8: 00 00 3A 98  00 01 5F 90  00 00 00 00  XX XX XX XX
00000BC8: XX XX XX XX  usw.

---

InitIRQ() benötig in diesem Beispiel als fünften Parameter den Wert $BB8 - ab diesem Speicherbereich stehen die Langworte (Adressen) zu den einzelnen Puffern. Und solange es kein Langwort dessen Wert null ist findet, interpretiert es jedes gesetzte Langwort als Adresse (in oberen Beispiel zwei).

Nehme zudem an, dass ab Adresse 9999 der String steht, der dem Interrupt einen Namen gibt, dann lautet der Aufruf für InitIRQ mit 22050 Hz wie folgt:
InitIRQ( 22050, 9999, 0, 0, 3000, 50000)
oder ausgeschrieben - in C:
InitIRQ( 22050, "Test", 0, 0, pufferliste, 50000)


Im Prinzip ganz einfach zu handhaben.

Und ja, Deine Puffer dürfen im FAST-RAM Bereich liegen - sie werden vom Interrupt nur gefüllt (ein Byte pro Timer-Tick) und dann nicht weiter beachtet.


Neue Version wurde hochgeladen. Benutzt weiterhin einen CIA-A Interrupt und eine DMA-freie Audio-Ausagbe. DMA-frei bedeutet, dass kein CHIP-RAM Puffer verwendet wird.
Du kannst das ändern, indem Du SetIRQAttrI( ihandle, 64) aufrufst (habe ich aber noch nicht ausprobiert).
Ein nochmaliger Aufruf stellt den voreingestellten Modus wieder her.

Gleiches gilt für die Audio-Ausgabe:
Die Audio-Ausgabe kannst Du unterdrücken, indem Du SetIRQAttrI( ihandle, 128) verwendest - oder wieder einschalten, bei nochmaligen, gleich lautenden Aufruf. Habe ich auch noch nicht ausprobiert...

Die Werte 64 und 128 sind Kippschalter. An, aus, an, aus, an, aus...


Sag mir mal ob jetzt die Audio-Ausgabe ansatzweise in Ordnung ist.


Gruß

Zitat:

---

Holger:

UAE emuliert den Amiga halt exakt.

Zitat:

---

Maik:

Scheinbar nicht exakt, ein echter Amiga bringt mehr CIA-Speed.
Hat mit Turbo nichts zu tun, denn ich habe den CIA ja nicht übertaktet oder so.

---

---

Zitat:

---

Aber mit Interrupts muss ich sagen das UAE bei der Customchip benutzung extrem in die Knie geht.

---

Zitat:

---

Versuch mal nur die WB in AGA zu fahren, das ist auf einem 500 MHZ Rechner langsamer als mit einem A600.

---

Zitat:

---

Ich habe die Bibliothek auch dahingehend geändert, dass der parallele Port nun auf Eingang geschaltet wird.

Zitat:

---

Das wird nicht helfen, es sei denn du schaltst den ParPort in der alten Version immer auf Ausgang.

---

---

Zitat:

---

Kannst du den anderen CIA-Timer wieder benutzen(da ging es ja)?

---

Zitat:

---

Die Wiederholungen resultieren aus der nicht hundertprozentigen [...]

Zitat:

---

Nein, das passiert wenn man einen zu großen Puffer nimmt, das hatte ich beim ASM Programm auch. Lässt man den Puffer beim Standard wert ist es okay.

---

---

Zitat:

---

Klappt das? Wäre schön - dann funktioniert nämlich etwas.

Zitat:

---

Ja, wesentlich besser als mit dem timer.device, vor allem weil ich auf den beiden Prozessoren nicht 2 verschidene
Zeiten angeben muss. Der Joyport scheint nicht gestört zu werden.

---

---

Zitat:

---

Ob's allerdings nach wie vor knackt, kann ich nicht sagen - hier hilft nur ausprobieren.

Zitat:

---

Du verwechselst jetzt das Knacken was mit dem ASM+C Programm minimal da war mit dem was ich jetzt meine - welches die
Parallel Information immer zwischendurch auf -127 runterschaltet.
Das jetzt ist viel schlimmer.

---

---

Zitat:

---

Das mit der Pufferliste hab ich nicht Verstanden:
(0)
(4)
(8)

damit würde man unter Basic jeweils 3 LONG's freilassen.
Also hab ich es in (0), (1), (2) geändert, also folgen die Adressen hintereinander. Geholfen hats aber nicht.

---

Zitat:

---

Ja, das versuche ich auch noch. Erstmal habe ich versucht das mit den Infrarot-Senden zu Timen.

---

Klappt das? Wäre schön - dann funktioniert nämlich etwas.

Zitat:

---

Serielle Schnittstelle? Das ist doch die Parallele.

---

Autsch.
Natürlich. Manchmal bin ich nicht im Vollbesitz meiner geistigen Kräfte...

Zitat:

---

Das Prog knackt genauso, zusätzlich wiederholt es bereits gespielte Teile und scheidet andere weg.

---

Zitat:

---

Es gab mehrere Programme von verschiedensten Programmierern die alle Fehlgeschlagen sind. UAE ist kein echter Amiga, er
Syncronisiert das Timing mit der Echtzeit auf kosten anderer aktivitäten.

---

Wie, UAE ist kein echter Amiga? Soll das heißen, isch haabe gaar keinen Amiga? Ische nix Amiganer?
Nee, Recht hast Du - aber was ich eigentlich sagen wollte ist, dass ich unter WindowsXP arge Probleme hatte, ein korrektes Timing hinzubekommen - dementsprechend war ich einigermaßen erfreulich erstaunt, dass das Timer-Device unter WinUAE ziemlich genau arbeitet.

Zitat:

---

ich habs erstmal was einfaches zusammengebastelt.
Also es geht bis 16000 HZ auf 060. Allerdings sind im Sample solche Knackser drin. Hört sich an wie eine sehr zerkratzte Platte. Es gehen Spikes auf -127. Beeinflusst der Interrupt irgenwie den BFE101 Register?

---

code:

---

POKEB MySample&+count&, PEEKB(&hBFE101) + 128
INCR count&

---

code:

---

DIM pufferListe 8   REM  8 Bytes reservieren = 2 Langworte

---

code:

---

POKEL pufferliste&, VARPTR(MySample&)

---

code:

---

POKEL pufferlist& + 4, 0   REM  Ende der Puffer-Liste

---

code:

---

ihandle& = InitIRQ&( 16000, "DigiTest", 0, 0, pufferListe&, 200004)   REM  Puffergröße = 200004 Bytes

---

code:

---

SetIRQAttrI&(ihandle&, 4)   REM  Normales Signal-Handling ausschalten

---

C code:

---

SUPERIOR ULONG CIAA_Code( REG(a1, struct TimeOutIRQData *tid) )
{
	LONG i;

	i = 2;

	/* Dürfen wir eine Aktion ausführen? */
	if ( tid->TimeOutFlag == ALIVE )
	{
		if (tid->IntType == IRQ_DIGITIZE)
			CallDigitizerCode( tid);	/* Rufe Digitizer auf */

		/* Falls Benutzer-Code vorhanden, diesen jetzt anspringen */
		if (tid->IRQUsersCode)
			tid->SendSignal = (LONG) tid->IRQUsersCode( (APTR) tid->IRQUsersData);

		/* Falls SendSignal != 0 wird Signal gesendet! */
		if (tid->SendSignal)
			Signal( tid->TimeOutTask, (1 << tid->TimeOutSignal) );
	}
	else	/* Nee, keine Aktion ausführen. Ende? */
	{
		if (tid->TimeOutFlag == KILL)	/* DeleteIrq() setzt dies - hat für uns */ 
			tid->TimeOutFlag = KILLED; /* aber eigentlich Bedeutung, da wir */
	}					/* diesen Punkt nie erreichen (Interrupt */
						/* schon gestoppt falls KILL gesetzt) */
	return i - 2;
}

---

Zitat:

---

Sag das nicht mir Im Grunde war das nur ein verzweifelter Versuch, seine enormen Abweichungen zu ergründen. Wie gesagt, auf meinen Kisten läuft das timer.device recht genau, bei ihm hingegen nicht.

---

Zu Deiner Information: Auch hier ist das Timer-Device sehr genau - und dass unter WindowsXP/WinUAE.
Also gehe ich davon aus, dass er einen simplen Programmierfehler irgendwo eingebaut hat.
Habe leider keine Zeit gefunden, den anderen Thread zu lesen. Werde das aber nächste Woche mal nachholen. Vielleicht fällt mir irgendetwas Ungewöhnliches auf.

Zitat:

---

Was da nun genau verkehrt läuft: Frag mich was Leichteres

---

Wenn Du mich schon so fragst: Wie wird das Wetter nächste Woche?

Gruß

Zitat:

---

Zweiter Grund (falls die Audio-Hardware keinen Prefetch benutzt - müsste das mal selber nachlesen - also ist diese Aussage nur mit Vorsicht zu genießen):
Je kleiner der verwendete Puffer, desto mehr Störgeräusche. Da der CIA-B Interrupt und die Audio-Hardware sich einen Speicherbereich teilen, und es sein kann, dass beide zum gleichen Zeitpunkt auf ein bestimmtes Datenword zugreifen wollen, bedingt durch die nicht hundertprozentige analoge Abtastrate, bekommt derjenige den Zugriff, der die höhere Priorität hat - und das ist der CIA-B Interrupt. Somit kommt es kurzzeitig zu diesem Effekt.

---

Zitat:

---

Multimon macht in etwa das selbe und knackt nicht. Also muss es ja möglich sein...

---

Zitat:

---

Das hab ich schon, da wird ein kurzer part dann mehrmals wiederholt.

---

Zitat:

---

Wenn ich gleichzeitig dnetc laufen habe und ein Benchmark mache bekomme ich mit 4 Kanälen um die 96000 keys/s. Mit 2 Kanälen
102000 keys/s und mit Multimon auf der selben Frequenz 116000 keys/s.
Der Wert ohne Monitor liegt bei 176000 keys/s.

---

Zitat:

---

Eine erkennung von DTMF tönen(Tonwahl) welche von einem Handy in den Sampler kommen decodieren.

---

Und dafür brauchst Du CD Qualität (44,1 kHz) ?


So, nun zu der Bibliothek:

Diese nennt sich "ire" und muss ins Libs-Verzeichnis.
Die "bmap" Datei habe ich mittels "fd2pragma" erstellt und sollte von Dir ohne weitere Anpassung unter MaxonBasic benutzt werden können.

Es gibt nur 5 Funktionen:

InitIRQ
StartIRQ
DeleteIRQ
SetIRQAttrI
GetIRQAttrI

InitIRQ kann sowohl normale Interrupts auslösen als auch digitalisieren.

void * InitIRQ( ULONG callsPerSecond, STRPTR irqname, LONG (*usersCode)(), APTR usersData, UBYTE **buffers, ULONG singleBufSize) (d0,a0,a1,d1,a2,d2)

callsPerSecond --- wie oft pro Sekunde soll der Interrupt aufgerufen werden, z.B. 16668.
irqname --- Name Deines Interrupts, z.B. "Maik's Interrupt".
usersCode --- Zeiger auf die Funktion die innerhalb des Interrupts aufgerufen wird - oder null falls keine eigene Routine aufgerufen werden soll.
usersData --- Zeiger auf eine Struktur oder Variable die dein "usersCode" auf dem Stack empfängt, darf auch null sein.
buffers --- falls gesetzt, wird der Digitizer aufgerufen! buffers zeigt auf einen Speicherbereich, in dem Du die Adressen Deiner FAST-RAM Puffer vermerkt hast. Der letzte Eintrag muss NULL (0) sein.
singleBufSize --- die Größe *eines* Puffer, d.h. falls Du jeden Puffer eine Größe von 20000 Bytes zugewiesen hast, musst Du hier 20000 eintragen. Bei zwei Puffern (buffers: Puffer1, Puffer2, NULL) macht das Summa Summarum 40000 Bytes FAST-RAM. Die einzelnen Puffer dürfen nicht in der Größe variieren!

Ein paar Beispiele:
ihandle = InitIRQ( 50, "Maik's Interrupt", NULL, 0, NULL, 0)

Hier wird dann jede fünfzigstel Sekunde ein Interrupt ausgelöst und ein Signal zu Deinem Hauptprogramm gesendet.
Du kannst mittels:
GetIRQAttr( ihandle, 2)
das Signal-Bit ermitteln, welches Dir signalisiert wird (z.B. für die Verwendung mit Wait() ).
Für Wait() musst Du das Signal-Bit in eine Signal-Maske umwandeln:
sigmask = (1 << GetIRQAttr( ihandle, 2))

ihandle = InitIRQ( 50, "Maik's Interrupt", (*usersCode)() &yourcode, &counter, NULL, 0)

Wie oben, nur wird hier noch deine "yourcode"-Routine aufgerufen und bekommt als Argument auf dem Stack die Adresse der Variable "counter".
Falls "yourcode" null zurückgibt, wird kein Signal an Dein Hauptprogramm gesendet. Nur wenn Du irgendeinen Wert zurückgibst, wird das Signal gesendet.

Du musst wissen, welche Prozessor-Register MaxonBasic benötigt und deren Inhalt irgendwo vor Aufruf von StartIRQ() ablegen und dann innerhalb von "yourcode" diese Registerinhalte restaurieren - und beim Verlassen von "yourcode" die ursprünglichen Registerinhalte für den originalen Interrupt-Code, der "yourcode" aufgerufen hat, wieder instand setzen.

-------------------------------------

ihandle = InitIRQ( 50, "Maik's Interrupt", SADD yourcode, SADD counter, 0, 0)

#asm
move.l a4,inhaltA4
move.l a5,inhaltA5
move.l a6,inhaltA6
#endasm

StartIRQ( ihandle)

------------------------------------

SUB yourcode( arg) STATIC
#asm
move.l 4(sp),argument ; Adresse von "counter"
movem.l D2-D7/A2-A6,-(sp)
movea.l inhaltA4,A4
movea.l inhaltA5,A5
movea.l inhaltA6,A6
#endasm
Dein Basic-Code hier - "argument" zeigt aufs Argument für "yourcode"
returnWert = 0 ; Kein Signal senden
#asm
movem.l (sp)+,D2-D7/A2/A6
move.l returnWert,D0
rts ; Muss RTS für Basic angegeben werden?
#endasm
-------------------------------------

DIM pufferListe (12)
DIM puffer1 (20000)
DIM puffer2 (20000)

POKEL( pufferListe(0), SADD puffer1)
POKEL( pufferListe(4), SADD puffer2)
POKEL( pufferListe(8), 0)

ihandle = InitIRQ( 16668, "Maik's Interrupt", 0, 0, SADD pufferListe, 20000)

Da wir nicht wollen, dass wir ein Signal für jeden Eintritt in den Interrupt erlangen, müssen wir das Signal-Handling für normale Signale ausschalten:

SetIRQAttrI( ihandle, 4)

Jetzt kann man (frau auch) StartIRQ( ihandle) aufrufen.

Und da wir informiert werden wollen, wann einer der beiden Puffer voll ist, müssen wir dessen Signal-Bit ermitteln:
sigmask = (1 << GetIRQAttr( ihandle, 1))

Jetzt mittels Wait( sigmask) horchen, ob eine Nachricht eintrifft.

Um die Adresse des Puffers zu erfahren, welcher voll ist, muss man dies verwenden:
vollerPuffer = GetIRQAttr( ihandle, 16)


Flaggen für Get/SetIRQAttrI():

1 = (get) - hole Signal-Bit das signalsiert, das ein Puffer voll ist.
2 = (get) - hole Signal-Bit das signalsiert, das Interrupt aufgerufen wurde.
4 = (set) - normale Signal-Handhabung ausschalten (Interrupt wird nicht signalsiert).
8 = (set) - normale Signal-Handhabung einschalten (Interrupt wird signalsiert).
16 = (get) - hole Adresse des Puffers, welcher voll ist.


Ich spreche kein Basic, daher weiß ich nicht ob das was ich oben verbrochen habe, so von einem Basic-Compiler/Interpreter akzeptiert wird - ich glaube kaum...

Archiv kann unter http://www.amimedic.de heruntergeladen werden.

Das (nährlose) Beispiel TimerIRQ digitalisiert und kann auch mit anderen Werten betrieben werden:
TimerIRQ 28801 - digitalsiert mit 28801 Hz!

Gruß

Zitat:

---

Ach ja, Du kannst STARTOFFSET auch einen größeren Wert zuweisen - dann startet die Audio-Ausgabe verzögert und somit stehen mehr Daten bereit, bevor eine hörbare Ausgabe erfolgt (kannst ja mal die halbe Größe von AUDSIZE probieren).
STARTOFFSET ist hier zu finden:

Zitat:

---

Und dann knackt es nicht?

---

---

Zitat:

---

Da die maximale Sampling-Frequenz 28801 Hertz beträgt

Zitat:

---

Bei einen DBL-PAL Screen geht dann das doppelte?

---

---

Zitat:

---

Ausserdem benutze ich jetzt nur noch 2 Audiokanäle, 4 nehmen nur mehr Resourcen.

---

Zitat:

---

Anbei, wieso sind 16000 Hz nicht ausreichend?

Zitat:

---

Weil es qualitativ schlecht ist. Da sind dann solche zischlaute und so

---

---

Zitat:

---

Ich habe früher mit 14000 Hz digitalisiert - und zwar ganze Musikstücke und diese sind
selbst nach heutigen Standards noch ganz manierlich anzuhören.

Zitat:

---

Ähm, mit PC-Lautsprecher vielleicht. Ich bin da doch anspruchsvoller.
Früher habe ich immer in etwa 22khz gesamplet. Heute 44khz in 16 Bit, also bei Musik die ich brennen will.

---

---

Zitat:

---

Soweit bin ich noch lang nicht...
Prinzipell brauche ich ja a) einen Monitor und b) ein (Speicher) aufzeichungsprogramm.
Also das ist jetzt a.

---

Da widerspreche ich Dir - zwar ungern, aber tue es trotzdem.
AudioGrabber2 bietet Dir beides. Schau Dir das Beispiel mal an.

Zitat:

---

Mit "Scout" kann ich dem ASM-Programm ein "Break" senden und es beendet
sich problemlos. Selbiges müsste man doch bewerkstelligen können.
Hab es schon mit Signal + SetSignal probiert, erfolglos.

---

Studiere mal die Beispiele - speziell die Interaktion zwischen Interrupt und Programm (Task). Dann weißt Du wie es gemacht wird.
Aber abgesehen davon, selbst das Senden eines CTRL-C Signals wird Dir nichts bringen - denn eine Frage bleibt: Wo hat das Programm (AudioGrabber) nun die Daten versteckt - und was passiert, wenn es ein CTRL-C Signal empfängt?
Beim Eintreffen des Signals werden alle Ressourcen freigegeben - und somit auch der Datenpuffer. Dementsprechend existieren die Daten nicht mehr!

Zitat:

---

Eine Library die Samplen kann?
Klingt nicht schlecht. Unter Basic kann man prinzipell alle Librarys benutzen, nur die Includes muss man sich ggf. selber machen.

---

Zitat:

---

Frage: Meinst Du auf Prozess/Task-Ebene oder das Beispiel mit dem Software-Interrupt?

Zitat:

---

Ein Standard warten mittels timer.device, also momentan sende ich Infrarot Signale mit etwa 1000-1500HZ. Beim 060er gebe ich 560 micros beim 030er 250 micros um das selbe ergebniss zu erhalten. Von Timing, Maschienenunabhängig kann also keine Rede sein.

---

---

Zitat:

---

Von Timing, Maschienenunabhängig kann also keine Rede sein.

---

code:

---

LOOP
	SendIO( timerrequest)
	....
	Sende Infrarot-Signal
	....
	signale = Wait( (1 << TimerSigBit) )
	IF signale AND (1 <<TimerSigBit) <> 0
		GOTO LOOP
	ENDIF
ENDLOOP

---

Zitat:

---

Ich nehme an dem timer.device fehlt es an effizienz, daher dürfte eine PPC-CPU da einiges kompensieren können.

---

Du würdest das nicht behaupten, wenn Du die betreffenden Routinen mal disassembliert hättest.
Diejenigen, die das originale AmigaOS programmierten, verstanden effizient und ressourcenschonend zu programmieren.
Leider hat das aber auch seine Kehrseiten...

Zitat:

---

Ausserdem verwendete ich das selbe Programm...
Dann hab ich es sogar Prozessorspezifisch Compiliert...

---

Ihr könnt mich ja dumm sterben lassen aber es wäre nett von euch wenn ihr mir stattdessen mal sagt, über welches Programm ihr euch unterhaltet... Erbarmen, bitte...

Zitat:

---

Das kann aber (und wird auch) "durchbrochen" werden. Z.B. durch das "Wait()en" auf das Signal vom timer.device, schau mal in die RKMs/AutoDocs (NDK3.9) zum Thema "Forbid()", da stehts nochmal.

Zitat:

---

Half aber gegen das leiern und Stoppte den Mauscursor.
Sollte ich Forbid dann wohl mehrfach innerhalb der Schleife benutzen?

---

---

Zitat:

---

Öhm... wo liegt das Problem? Open(), Write(), Close(), fertig.

Zitat:

---

In Assembler sind die aufrufe etwas schwieriger...

---

---

code:

---

_WriteBufferContents
	movem.l	D2-D4/A6,-(sp)
	movea.l	_DOSBase(pc),A6
	move.l	_DateiName(pc),D1
	move.l	#1006,D2
	jsr	_LVOOpen(A6)
	move.l	D0,D4
	beq.s	_error
	move.l	D0,D1
	move.l	_PufferAdresse(pc),D2
	move.l	_PufferLaenge(pc),D3
	jsr	_LVOWrite(A6)
	move.l	D0,D2
	move.l	D4,D1
	jsr	_LVOClose(A6)
	cmp.l	D2,D3
	bne.s	_error
	moveq	#1,D0
_out
	movem.l	(sp)+,D2-D4/A6
	rts
_error
	moveq	#0,D0
	bra.s	_out

_DOSBase
	ds.l	1
DateiName
	ds.l	1
PufferAdresse
	ds.l	1
PufferLaenge
	ds.l	1

---

Zitat:

---

Im Internet hab ich schon gesucht, ausser was mit dem Seriell Port fand ich nichts.

---

Zitat:

---

Ausserdem verwendete ich das selbe Programm...
Dann hab ich es sogar Prozessorspezifisch Compiliert...

Zitat:

---

Ich habe nie etwas anderes gesagt.

---

---

Zitat:

---

Ich hatte ihm schon einmal zu verstehen gegeben, daß das Multitasking da eine Rolle spielen kann.

---

Zitat:

---

In Sachen Verständnis hätte evtl. auch ein Hinweis auf den VBI helfen können, dessen Beispielprogramm im RKM ich heute "wiederentdeckt" habe. Sehr trivial, wie ich fand, und für das Verständnis der Feinheiten, auf die vorher schon eingegangen wird, auch recht hilfreich.

---

Zitat:

---

Was ich allerdings bis heute nicht begreife ist, wie er so schlechte Ergebnisse bekommen kann. Auf meinen Maschinen hier ist das timer.device auch bei recht kurzen Intervallen "stabil" genug, um nicht dermaßen gigantische Abweichungen zu produzieren. Insofern wäre es schon recht interessant zu erfahren, woran es bei ihm hapern könnte.

---

Zitat:

---

Mal davon ab, wenn die Puffer groß genug sind kannst Du den Goertzel sicherlich auch "direkt" drüberrennen lassen, es wird ja im Interrupt weitergesamplet (am schlauesten in den nächsten Puffer).

Zitat:

---

Ja, da müsste ich dann wieder zu C übergehen.

Zitat:

---

Ich dachte, der Basic-Goertzel wäre schnell genug für Echtzeit?

---

---

---

Wenn er den gleichen Algorithmus meint wie ich und er mit 28kHz oder gar 44kHz digitalisieren will, wird das nicht in Echtzeit unter Basic gehen - zumindest nicht mit 'ner 030 CPU.


Tschö!

Zitat:

---

Kannst Du das Beispiel mittels Holgers Hinweis assemblieren?

Zitat:

---

Ja, geht. Naja bis auf diese click-störungen.

---

---

code:

---

Original:
	cmpi.l	#4,D0	; Indicator for start audio (leading bytes)
	bne.s	.out	; If not...
in
	cmpi.l	#AUDSIZE/2,D0	; Indicator for start audio (leading bytes)
	bne.s	.out	; If not...
ändern.

---

Zitat:

---

Jetzt muss ich das ganze noch auf eine bessere Frequenz bringen [...]

---

Zitat:

---

[...] und herrausfinden wie man ein CTRL-C an das Programm schickt.

---

Zitat:

---

Am besten währe natürlich das vollständige Verstehen.

---

Zitat:

---

Momentan hab ich herrausgefunden das das timer.device unter einem 030er noch nichtmal mit 1500 HZ korrekt arbeitet...

---

Das ist doch schon mal ein Anfang.

Frage: Meinst Du auf Prozess/Task-Ebene oder das Beispiel mit dem Software-Interrupt?
Was ich vergessen habe zu erwähnen ist, dass der Agnus-Baustein bedingt durch das Zusammenspiel aller Hardware-Komponenten nur in festgelegten Intervallen Software-Interrupts auslösen darf/kann. Weil ich mich aber nie damit tiefer beschäftigt habe, gehe ich davon aus, dass nur entsprechend der Bildschirmwiederholfrequenz Software-Interrupts ausgelöst werden. Um das zu verifizieren müsste ich aber erstmal das Hardware-Reference-Manual wieder finden... (dem Betreffenden, der eine abfällige Bemerkung über meinen Ordnungssinn macht, haue ich die Kartoffel vom Kopf ).
Wie gesagt, ich benutze Software-Interrupts in abgewandelter Form - bei mir wird 50-mal in der Sekunde eine Aktion durchgeführt - und nicht 14000 oder gar 28000-mal. Das überfordert den Agnus-Chip.

Es würde mich interessieren, ob unter MorphOS/OS4 diese Einschränkung weiterhin besteht.


Auf Prozess/Task-Ebene wage ich zu bezweifeln, ob Du das Timing überhaupt in den Griff bekommst - zu viele Faktoren spielen hier eine Rolle.


Gruß

Zitat:

---

Übrigens ist AsmOne (bzw. dessen Grafikkarten-fähiges Pedant
AsmPro) nicht einfach nur ein Assembler, sondern eine komplette
Entwicklungsungebung mit grafischer Oberfläche, Monitor,
Debugger und Vielem mehr !
Dabei besteht er nur aus einer einzigen Datei (plus Config)
und kann dadurch praktisch auf jedem Amiga-System bei gleich-
zeitig sehr ergonomischer Benutzführung verwendet werden.

Fazit: Unbedingt anschauen !

---

Nee, Danke. Seit 1992 benutze ich ausschließlich Devpac 3 für meine Assembler-Projekte.
Devpac heißt die gesamte IDE, GenAm ist der Assembler, MonAm der Debugger und der Devpac nennt sich auch der Texteditor und es ist wohl das Beste kommerzielle Assembler Paket, dass je für den Amiga entwickelt wurde.
Vorher habe ich wie viele andere auch den ASSEM-Assembler (MetaComCo) und ALink verwendet, als dann SEKA rauskam, den SEKA-Assembler, der war sehr viel schneller als die Verbindung ASSEM und ALink - und man brauchte nur eine Diskette, auf der die System-Dateien (S, C, LIBS etc. - die Workbench war ja was für Memmen ) sowie der Assembler Platz fanden. Das waren noch Zeiten...

Zitat:

---

@jolo: Alles ganz falsche Vermutungen ;-)

---

Yep, damit habe ich nicht gerechnet...
Ich habe vorausgesetzt, dass Maik schon eigenständig Programme in Assembler verfasst hätte.
Mein Fehler...


Gruß