Registerzugriff in C - amiga-news.de Forum

amiga-news.de Forum > Programmierung > Registerzugriff in C

[ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 3 -4-

[ - Beitrag schreiben - ]

25.11.2007, 22:36 Uhr

MaikG
Posts: 5172
Nutzer

>Das Timing wurde komplett geändert.

Habe ich jetzt beim Infrarot-Senden eine Abweichung dadurch?

>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.

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.

[ - Antworten - Zitieren - Direktlink - ]

28.11.2007, 00:15 Uhr

jolo
Posts: 110
Nutzer

@MaikG:

Hi.

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

Zitat:
Einfach einen Wert nehmen der grade Teilbar ist.

Das wird nicht funktionieren, da beide, die Audio-Hardware und die CIA-Chips unterschiedliche Taktfrequenzen haben.

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.

Ja, Klangeinbußen gibt es - aber das Timing (CIA zu Audio) war nicht akkurat (50 Hz vs. 60 Hz...).
Zudem hat die DMA-freie Audioausgabe keinerlei Probleme mit Abschnitten die doppelt wiederholt werden.
Es wird analog das ausgegeben, was rein kommt.

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?

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

Zitat:
Das Timing wurde komplett geändert.

Zitat:
Habe ich jetzt beim Infrarot-Senden eine Abweichung dadurch?

Nein, für normale Interrupt-Aufgaben, also alles ohne Digitalisierung, bleibt alles beim Alten.
Nur für die Audio-Ausgabe wird eine Neuberechnung durchgeführt.

Mir ist allerdings ein Malheur passiert und ich habe eine Version mit halber Ablaufverfolgung hochgeladen, die eigentlich nur für mich bestimmt war. Dementsprechend müsste es bei Deiner Version zu Störungen bei der Wiedergabe kommen (Abschnitte werden des Öfteren wiederholt).

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.

Zu 1)
Du digitalisierst auf Prozess-Ebene? Dementsprechend benutzt Du von Basic aus einen Interrupt, um 22000-mal in der Sekunde ein Signal zu empfangen - und wenn es eintrifft liest Du den Wert der am parallelen Port anliegt?
Wenn dem so ist kann ich Dir jetzt schon sagen, dass Du das niemals auf Prozess-Ebene schaffen wirst - okay, vielleicht mit einem neuen OS und einer CPU die um ein vielfaches schneller ist als Deine 68060 - aber nicht mit der jetzigen Software und Hardware.

Extra für diesen Zweck habe ich einen Digitizer auf Interrupt-Ebene entworfen. Er sollte Dir die Arbeit abnehmen.

Zu 2)
Wie schon im letzten Beitrag von mir geschildert, soll die Audio-Ausgabe nur grob einen Überblick über die tatsächliche Digitalisierung geben. Leider, wie oben geschildert, habe ich eine Version hochgeladen, die mit dem falschen Compiler-Aufruf erstellt worden ist - hier ist die Wiedergabe nicht ganz so genau wie bei der Version die Du eigentlich verwenden müsstest.

Um eine Ablaufverfolgung zu starten, löscht die Version die Du jetzt besitzt, alle Audio-Interrupt-Quellen und wartet solange, bis diese durch die Hardware neu gesetzt wurden. Dementsprechend kann ich exakt bestimmen, wie viele Bytes pro Sekunde von der Audio-Hardware ausgegeben werden, bzw. wie viele Bytes pro Sekunde der Interrupt zu langsam oder zu schnell läuft. Der Nachteil der damit erkauft wird, ist, dass die Audio-Hardware kurzzeitig aus dem Tritt gebracht wird, da sie selber auf diese Audio-Interrupt-Quellen angewiesen ist, bzw. für einen Störungsfreien Ablauf diese Quellen nicht zurückgesetzt werden dürfen.

SampleManager (hallo Thilo - nettes Programm!) habe ich mal runtergeladen und über die Dateien gejagt, die ich hier digitalisiere. Es sagt mir kein Crackle (Knistern?). Dementsprechend gehe ich davon aus, dass der Interrupt-Code in Ordnung ist. Bleibt nur noch die Frage was mit den Daten vom parallelen Port geschieht.
Ich kann mir nicht vorstellen, dass der CIA-A Interrupt irgendwelchen Einfluss auf die Daten vom parallelen Port hat, da ansonsten das von Commodore vorgesehen Handshake zwischen CIA-A und CIA-B beim Senden oder Empfangen von Daten am parallelen Port gestört sein würde - und ich das als Hardwarebug bezeichnen würde, der mindestens mit dem Erscheinen des ECS-Chipsatz hätte verschwunden sein müssen.
Zudem bist Du Dir auch nicht sicher, ob es an Deinem Programm liegt oder an der Bibliothek. Daher würde ich Dich bitten, mir Klarheit zu verschaffen. Tauchen Probleme beim Digitalisieren mittels Digi auf oder nicht?

Zum CIA-B Interrupt:
Meiner Meinung nach sollte dieser gar nicht verwendet werden, jedenfalls nicht bei gleichzeitiger Benutzung der Audio-Hardware - da die Audio-Hardware Interrupts der Ebene 4 generiert und bei der Benutzung eines Level-6 Interrupts diese nicht zum korrekten Zeitpunkt erstellt werden können - womit die Audio-Hardware dann aus dem Tritt kommt und es zu Störungen bei der Wiedergabe kommen muss (jedenfalls geschieht dies hier unter WinUAE). Somit ist das ASM-Beispiel eigentlich ein gutes Beispiel wie man es nicht machen sollte...

Anbei, SetIRQAttrI( ihandle, 512) schaltet vom 8-Bit Modus in den 16-bittigen und umgekehrt. Dementsprechend kannst Du die Audio-Ausgabe über AHI bewerkstelligen, falls Du möchtest.
Um die aktuelle Position in Deinem FAST-RAM Puffer zu erfahren, kannst Du:
GetIRQAttrI( ihandle, 1024) benutzen - es retourniert die Position des aktuellen Samples im Puffer (FAST-RAM) - bei 16-Bit Samples musst Du den Wert mit 2 multiplizieren - dann hast Du die Byte-Position.
Dementsprechend kannst Du z.B. auf Position 32 warten und dann mittels AHI die Audio-Daten ausgeben - falls Du dies möchtest.

Neue Version ohne Ablaufverfolgung wurde hochgeladen.

Gruß

[ - Antworten - Zitieren - Direktlink - ]

28.11.2007, 11:15 Uhr

MaikG
Posts: 5172
Nutzer

>Zudem hat die DMA-freie Audioausgabe keinerlei Probleme mit
>Abschnitten die doppelt wiederholt werden.

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

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

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

>Zu 1)
>Du digitalisierst auf Prozess-Ebene? Dementsprechend benutzt Du von Basic aus einen Interrupt, um 22000-mal in der Sekunde ein Signal zu empfangen - und wenn es eintrifft liest Du den Wert der am parallelen Port anliegt?
>Wenn dem so ist kann ich Dir jetzt schon sagen, dass Du das niemals auf Prozess-Ebene schaffen wirst - okay, vielleicht mit einem neuen OS und einer CPU die um ein vielfaches schneller ist als Deine 68060 - aber nicht mit der jetzigen Software und Hardware.

Nein, das macht die Library. Ich setzte nur noch beim Start den
Parallel-port auf Eingang

>Zudem bist Du Dir auch nicht sicher, ob es an Deinem Programm liegt
>oder an der Bibliothek. Daher würde ich Dich bitten, mir Klarheit
>zu verschaffen. Tauchen Probleme beim Digitalisieren mittels Digi
>auf oder nicht?

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

>Somit ist das ASM-Beispiel eigentlich ein gutes Beispiel wie man es
>nicht machen sollte...

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

>Neue Version ohne Ablaufverfolgung wurde hochgeladen.

Jetzt geht die Monitorausgabe nicht mehr...

Hier das Programm:

code:

' $INCLUDE Exec.bh
' $INCLUDE dos.bh
' $INCLUDE Timer.bh

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

DECLARE FUNCTION InitIRQ& LIBRARY
DECLARE FUNCTION StartIRQ& LIBRARY
DECLARE FUNCTION DeleteIRQ& LIBRARY
DECLARE FUNCTION GetIRQAttrI& LIBRARY
DECLARE FUNCTION SetIRQAttrI& LIBRARY

REM $NOEVENT
REM $NOOVERFLOW
REM $NOLINES

POKEB &hBFE301,0 REM Parallelport auf Eingang


MySample&=AllocVec(200004, MEMF_PUBLIC& OR MEMF_CLEAR&)

test&=&h45454545 REM String für InitIRQ& "AAAA"

t!=TIMER rem Zeit des Starts festhalten

DIM pufferliste&(12)
pufferliste&(0)=MySample&
pufferliste&(1)=NULL&

ihandle&=InitIRQ&(20000, VARPTR(test&),NULL&,0,VARPTR(pufferliste&(0)),200000) REM 16000

sigmask&=(1<<GetIRQAttrI&(ihandle&,1))

junk&=SetIRQAttrI&(ihandle&,4)

REM junk&=SetIRQAttrI&(ihandle&,128) REM AudioAusgabe ON/OFF

junk&=StartIRQ&(ihandle&)

junk& = xWait&(sigmask&) Rem warten bis 200kb voll sind.


PRINT TIMER-t! rem verbrauchte Zeit wiedergeben (Knapp über 10s)
junk&=DeleteIRQ&(ihandle&)


Rem Daten aus den vollen Puffer als Datei schreiben.
fh& = xOpen&(SADD("ram:sample"+CHR$(0)), MODE_NEWFILE&)
 IF fh& THEN
  junk& = xWrite&(fh&,MySample&,200000)
  junk& = xClose&(fh&)
 END IF

FreeVec MySample& rem Speicher Freigeben

[ - Antworten - Zitieren - Direktlink - ]

28.11.2007, 22:35 Uhr

jolo
Posts: 110
Nutzer

@MaikG:

Hi.

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

Leider wurden hier auf meiner Maschine Abschnitte doppelt wiedergegeben - das habe ich auf ein Minimum in der letzten Version reduzieren können (60 Hz / 50 Hz Timing).

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.

Hier geht's.

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

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

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

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

Hier funktioniert das nicht so gut.

Zitat:
Jetzt geht die Monitorausgabe nicht mehr...

Was heißt Monitorausgabe?

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

Habe die Demo-Version von MBasic runtergeladen und Dein Programm abgewandelt. Hier funktioniert es.

Gruß

[ - Antworten - Zitieren - Direktlink - ]

29.11.2007, 11:24 Uhr

MaikG
Posts: 5172
Nutzer

>Leider wurden hier auf meiner Maschine Abschnitte doppelt
>wiedergegeben - das habe ich auf ein Minimum in der letzten
>Version reduzieren können (60 Hz / 50 Hz Timing).

Du hast doch nur UAE oder?

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

Ich glaub schon.

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

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

>Was heißt Monitorausgabe?

Die Wiedergabe während des Samplens, wenn man diese aktiviert
hat.

>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)!

Bei mir sinds 10.1x Sek.

>Habe die Demo-Version von MBasic runtergeladen und Dein Programm
>abgewandelt. Hier funktioniert es.

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

[ - Antworten - Zitieren - Direktlink - ]

30.11.2007, 19:47 Uhr

jolo
Posts: 110
Nutzer

@MaikG:

Hi.

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

Zitat:
Du hast doch nur UAE oder?

Ja, schon. Trotzdem kann ich es testen. Habe drei Möglichkeiten:
1) Die Bibliothek besteht zusätzlich aus einer Audio-Datei (2,2 Mbytes). Im Interrupt wird nicht das Datenbyte vom parallelen Port gelesen sondern das entsprechende Byte in der Audio-Datei.
2) Am Ende des Interrupt-Codes wird ein Byte der Audio-Datei auf den parallelen Port geschrieben.
3) AudioGrabber.asm wurde abgewandelt um aus einer Audio-Datei das entsprechende Byte auf den parallelen Port zu schreiben - hat allerdings den Nachteil, dass damit nur Frequenzen bis zu 7 kHz verwendet werden können (wie gesagt, WinUAE ist bei der Emulation des Chip-Satzes nicht so schnell wie die echte Hardware).

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

Zitat:
Ich glaub schon.

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

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

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

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

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.

Ich kann nicht mit 22 kHz digitalisieren - sondern bis maximal 14. Dementsprechend sind 200004 Bytes durch 14840 Bytes/Sekunde 13,4 Sekunden und nicht 16,1. Die Funktion TIMER ist mehr als ungenau.

Zitat:
Hier funktioniert es.

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

Komisch.
Hier funktioniert es ohne Knackser - dementsprechend muss ich etwas übersehen haben, was WinUAE ignoriert die originale Hardware aber nicht.

Gruß

[ - Antworten - Zitieren - Direktlink - ]

01.12.2007, 00:13 Uhr

MaikG
Posts: 5172
Nutzer

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

der code steht doch oben:

>junk&=SetIRQAttrI&(ihandle&,4)

das war doch was du meinst?

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

Hab deine Email Adresse aber nicht...

>Die Funktion TIMER ist mehr als ungenau.

Das muss an WinUAE liegen.

>Hier funktioniert es ohne Knackser - dementsprechend muss ich etwas
>übersehen haben, was WinUAE ignoriert die originale Hardware aber
>nicht.

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

[ - Antworten - Zitieren - Direktlink - ]

01.12.2007, 10:14 Uhr

jolo
Posts: 110
Nutzer

@MaikG:

Hi.

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?

Für mich sind das Senden von Infrarotsignalen und das Digitalisieren zwei Paar Schuhe - dementsprechend zwei Programme.
Beim Senden von Infrarotsignalen bist Du auf Signale vom Interrupt angewiesen um das Timing hinzubekommen; beim Digitalisieren aber nicht.
Das Beispiel, dass Du aufzeigst, dient dem Digitalisieren - nicht dem Senden von Infrarotsignalen.

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

Zitat:
Hab deine Email Adresse aber nicht...

Habe übers Forumsformular Dir meine Email-Adresse zukommen lassen.

Zitat:
Die Funktion TIMER ist mehr als ungenau.

Zitat:
Das muss an WinUAE liegen.

Nee, daran dass man oft bei der Amiga-Programmierung auf Programmierer stößt, die ein bestimmtes Verhalten voraussetzen - was aber nie von Commodore als solches dokumentiert wurde.
Mache solche Fehler selber…

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

Eigentlich schon. Da aber Deine Timing-Intervalle an die Grenzen des Machbaren stoßen, wird's ein wenig kritisch.

Gruß

[ - Antworten - Zitieren - Direktlink - ]

01.12.2007, 10:22 Uhr

MaikG
Posts: 5172
Nutzer

>Für mich sind das Senden von Infrarotsignalen und das Digitalisieren zwei Paar Schuhe - dementsprechend zwei Programme.

Ja, das Beispiel da oben ist zum Digitalisieren.

Das Senden von Infrarotsignalen Funktioniert doch seit der
1.Version schon.

>Habe übers Forumsformular Dir meine Email-Adresse zukommen lassen.

Hab dir einen Sample gemailt.

[ - Antworten - Zitieren - Direktlink - ]

05.12.2007, 12:05 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von jolo:
Komisch.
Hier funktioniert es ohne Knackser - dementsprechend muss ich etwas übersehen haben, was WinUAE ignoriert die originale Hardware aber nicht.

Ich kann Dir auf Anhieb etwas nennen, in dem sich WinUAE und ein echter Amiga unterscheiden:

Zitat:
Original von jolo:
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.

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 und natürlich, um nur ein Beispiel zu nennen, wesentlich empfindlicher auf Störungen von anderer Software reagiert, wenn man z.B. die Ressource nicht korrekt gelockt hat. Es gibt viele mögliche Fehlerquellen.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.12.2007, 19:01 Uhr

jolo
Posts: 110
Nutzer

@Holger:

Hi.

Zitat:
Es gibt viele mögliche Fehlerquellen.

Das ist ein wunder Punkt - Maik und ich probieren derzeit ein wenig herum, da anscheinend Störungen von außen die Daten am parallelen Port beeinträchtigen.

Auch habe ich zwei Fehler in der Ire-Bibliothek ausgemacht:
1. Der CIA-A Interrupt wurde mit einer falschen Maske gestartet.
2. INTENA und INTREQ wurden vertauscht - was unter einem echten Chip-Satz fatale Folgen haben kann.

Dementsprechend habe ich das schon korrigiert - INTENA und INTREQ werden jetzt auch nicht mehr benutzt.

Wenn's denn irgendwann so läuft wie es laufen soll, wird der Quell-Code beigefügt - im Moment sind zu viele #ifdefs drin und ein Mix aus Deutsch und Englisch...

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 [...]

Das ist richtig - allerdings fällt mir keine bessere Lösung ein um das hier unter WinUAE auszuprobieren.
Ich könnte natürlich von Windows aus Daten auf den Port zaubern - aber um ehrlich zu sein, ich hatte schon mal gravierende Probleme bezüglich des Timings unter XP dass ich da lieber die Hände von lasse...

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

In neueren Versionen wird der parallele Port gelockt - allerdings hat das meines Wissens nach keinen Einfluss auf irgendwelche Werte, da hier nur sichergestellt wird, dass ausschließlich ein Nutzer einen Baustein (Centronics) verwenden kann.

Was ich derzeit mache, ist das DDRA und das DDRB Register zu initialisieren, abgesehen vom Generieren des Interrupts.

Maik hat mittels eines anderen Digitizer herausgefunden, dass die Störgeräusche auch unter diesem aufgezeichnet werden.
Verantwortlich dafür scheint ein kommerzielles Programm zu sein, welches einen CIA-B Timer-B Interrupt generiert um eine Hardware-Erweiterung nutzbar zu machen.
Verantwortlich ist allerdings das falsche Wort: Ich gehe davon aus, dass dieses kommerzielle Programm alles richtig macht, jedoch es dadurch zu Störungen des Sound-Samplers (sprich Digitizer) kommt. Und hier muss ich jetzt irgendwie eine Lösung finden, die beiden, also diesem kommerziellen Programm als auch dem Digitizer der Ire-Bibliothek gerecht wird.
Mal schauen ob ich's hinbekomme.

Gruß

[ - Antworten - Zitieren - Direktlink - ]

19.12.2007, 21:25 Uhr

jolo
Posts: 110
Nutzer

Hallo.

Ich habe mit Hilfe von Maik die Bibliothek dahingehend zum Laufen gebracht, dass nun diese Knackser während der Aufnahme und dem gleichzeitigen Betrieb eines kommerziellen Programms nicht mehr aufgezeichnet werden.

Ein kleiner Trick hilft hier - meines Wissens nach von Bert Jahn (WHDLoad) - und als Interrupt Acknowledge Fix bekannt:
Unter schnellen Prozessoren (68040 und höher) kann es passieren, dass ein Interrupt-Acknowledge unter geht, falls kurzeitig danach der Supervisor-Modus (Interrupts werden im Supervisor-Modus abgearbeitet) verlassen wird (rte). Was hier hilft, ist vor dem eigentlichen Bestätigen (Acknowledge) eines Interrupts und verlassen des Supervisor-Modus eins der CIA-Register oder eins der Custom-Register auszulesen.
Dann klappt es wieder mit der Bestätigung (im ROM).

Maik hat mich mit der Nase darauf gestoßen...

Ich ziehe meinen Hut vor Bert Jahn - ich selber wäre nie auf die Idee gekommen...

Neue Version inklusive Quellcode kann unter http://www.amimedic.de heruntergeladen werden.

Gruß

[ - Antworten - Zitieren - Direktlink - ]

1 2 3 -4-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Registerzugriff in C

[ - Suche - Neue Beiträge - Registrieren - Login - ]