amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste 2 3 4 5 6 -7- 8 9 10 11 12 Ergebnisse der Suche: 332 Treffer (30 pro Seite)
geit   [Ex-Mitglied]

25.09.2007, 18:53 Uhr

[ - Direktlink - ]
Thema: InfraRexx
Brett: Amiga, AmigaOS 4

@MaikG:

Was die Frequenzen angeht, so liegen 95% aller Fernbedienungen bei 37Khz oder 39Khz.

100% identische Signale bekommst Du dann aber auch nicht, da es immer unterschiedliche Längen sein werden. Selbst wenn die Hardware das Messen erledigt hast du Tolleranzen.

Hier mal ein Link mit IR spezifischen infos:

http://www.sbprojects.com/knowledge/ir/ir.htm

Geit
 
geit   [Ex-Mitglied]

10.08.2007, 15:58 Uhr

[ - Direktlink - ]
Thema: Autoscroll-Screens und mehr
Brett: Programmierung

Das mit den ~0 steht natürlich nirgendwo, da es total Banane ist.

Die richtigen Werte lauten: STDSCREENWIDTH und STDSCREENHEIGHT.

Das kann man in den RKRM Libraries unter "Screen Attributes" nachlesen. (Seite 48)

Geit
 
geit   [Ex-Mitglied]

22.06.2007, 10:39 Uhr

[ - Direktlink - ]
Thema: Datatypes ohne Screen?
Brett: Programmierung

Zitat:
Original von thomas:
Zitat:
Das ist schon richtig, aber damit das Ergebnis maximal schnell ist, sollte es schon 1:1 sein. Wenn das Kopieren und besonders das Umwandeln der Pixel die Graka macht, ist das ja gut und schön, aber wenn nicht wird es sehr langsam.

Warum glaubst du, daß bei Datatypes mit Screen die Grafikkarte das Pixelformat umwandelt und wenn du selbst BltBitmap benutzt, nicht ? Die Datatypes können auch nur entweder die Umwandlung per selbst geschriebenem Code machen, also per CPU, oder mit den Funktionen der (cyber)graphics.library, also mit BltBitMap oder WritePixelArray. Und das kannst du auch selbst machen. Lege einfach eine Bitmap mit dem richtigen Pixelformat an und blitte die DT-Bitmap da hinein. Schneller kannst du es nicht kriegen.


Das hab ich doch gar nicht gesagt.

Mir ist schon klar, wie das DTSystem die umrechnet. Aber wenn ich später Dinge von Hand mache, oder sonstwie ein bestimmtes Pixelformat brauche, dann hab ich den Salat. Ich lade die Daten einmal, was schon recht lange dauert (Amithlon braucht >5 Sekunden) und danach werden die Daten nur noch als Quelle benutzt und nicht einmal, sondern mehrfach in der Sekunde. (u.a. mit Blt#?BitMap() Da sollte schon alles zusammen passen.

Geit

 
geit   [Ex-Mitglied]

22.06.2007, 03:04 Uhr

[ - Direktlink - ]
Thema: Datatypes ohne Screen?
Brett: Programmierung

Zitat:
Original von tboeckel:
Aber ohne Bezug (kein Screen, kein Fenster) dürfte das eher schlecht aussehen.


Ja, genau. Das war mein Problem. Ich meine es gibt einen TAG um einen Screen zu definieren, dessen Bitmap genommen wird. Warum gibt es dann keinen TAG bei dem man direkt eine friendly Bitmap angeben kann?

Zitat:
Warum müssen es denn unbedingt fried-Bitmaps sein?

Weil ich optional auch andere Systeme einbinden will, die deutlich schneller sind als DT, z.B. Reggea, das nur ein bestimmtes Pixelformat liefert/unterstützt.

Zitat:
Per BltBitmapRastport() sollten sich doch beliebige Bitmaps malen lassen.

Das ist schon richtig, aber damit das Ergebnis maximal schnell ist, sollte es schon 1:1 sein. Wenn das Kopieren und besonders das Umwandeln der Pixel die Graka macht, ist das ja gut und schön, aber wenn nicht wird es sehr langsam. Ob eine, wenn auch minimale, Beschleunigung bei Graka-Support passiert, entzieht sich aber meiner Kenntniss.

Der Hauptgrund, warum mich das stört ist, dass das Einladen der Daten schon recht lange dauert und der Nutzer auf einen blanken Screen starrt, der nur schon so früh da ist, weil ich die Grafiken nach ihm ausrichte.

Geit
 
geit   [Ex-Mitglied]

20.06.2007, 22:13 Uhr

[ - Direktlink - ]
Thema: Datatypes ohne Screen?
Brett: Programmierung

Mir ist so, als hätte es dieses Thema schon gegeben, aber ich habe es trotz Suche nicht gefunden.

Wenn ich ein Datatype-Object erzeuge, kann ich einen Screen angeben, zu dem die geladene BitMap dann friendly ist. Was aber, wenn man den Screen noch gar nicht geöffnet hat, oder die Daten gar nicht auf einen Screen sollen?

Muß ich jetzt etwa einen nicht sichtbaren Screen öffnen, damit ich die Bitmap im entsprechenden Pixelformat bekomme, oder gibt es einen Trick, mit dem ich die Friendly BitMap angeben kann?

Finden tue ich jedenfalls nichts.

Geit
 
geit   [Ex-Mitglied]

06.06.2007, 13:44 Uhr

[ - Direktlink - ]
Thema: Datatypes und BitMap
Brett: Programmierung


Alles klar!

Danke!

Ich bin nur froh nicht jedesmal auf MOS umschalten zu müssen um zu testen.

Geit

 
geit   [Ex-Mitglied]

06.06.2007, 13:21 Uhr

[ - Direktlink - ]
Thema: Datatypes und BitMap
Brett: Programmierung


Nachtrag:

Wenn ich

DoMethod( so->SO_ImageObject, DTM_PROCLAYOUT, NULL, 1);

vorschiebe, geht es auch unter Amithlon.

Jetzt frage ich mich natürlich mache ich was falsch, oder der Datentyp under MOS?

?(

Geit



 
geit   [Ex-Mitglied]

06.06.2007, 13:11 Uhr

[ - Direktlink - ]
Thema: Datatypes und BitMap
Brett: Programmierung

Kann mir mal jemand sagen, was hier nicht richtig funktioniert?

Unter Amithlon bekomme ich keine BitMap, unter MorphOS läuft alles, wie erwartet.

Den Datentyp habe ich unter Amithlon mal gegen den AK-DT ausgetauscht. Es ist auch egal, ob PNG oder jpg.

Das gleiche Binary geht unter MOS und unter Amithlon bekomme ich einfach keine Bitmap.

Den BitMapHeader bekomme ich, die Datei wurde also geladen und dekodiert.

code:
if( (so->SO_ImageObject = NewDTObject( so->SO_ImageName,
                DTA_GroupID, GID_PICTURE,
                OBP_Precision, PRECISION_EXACT,
                PDTA_Screen, ss->SS_Screen,
                PDTA_FreeSourceBitMap, TRUE,
                PDTA_DestMode, PMODE_V43,
                PDTA_UseFriendBitMap , TRUE,
                TAG_DONE)) )
 {
  GetDTAttrs( so->SO_ImageObject,
      PDTA_BitMap,       (ULONG*) &bm,
      PDTA_BitMapHeader, (ULONG*) &bmh,
      TAG_DONE );

  if( bmh && bm )
  {
   so->SO_ImageWidth = bmh->bmh_Width;
   so->SO_ImageHeight = bmh->bmh_Height;
  } else {
   DisposeDTObject( so->SO_ImageObject );
   so->SO_ImageObject = NULL;
  }
 }
}




Geit


[ Dieser Beitrag wurde von geit am 06.06.2007 um 13:18 Uhr geändert. ]
 
geit   [Ex-Mitglied]

15.04.2007, 13:53 Uhr

[ - Direktlink - ]
Thema: IFF-ILBM 48/64 bit Erweiterung
Brett: Programmierung

IFF-RGFX ist auch ein schönes Format, das sehr flexibel ist und kompression via XPK erlaubt.

Heute noch Formate zu bauen, die Planar zu speichern ist in der Tat Käse. Ein altes Format beizubehalten ist ja gut und schön, aber der Aufwand für die Dartstellung und das Scheiben stehen in keinem Verhältnis zum Nutzen, denn die Dateien dürften noch deulich riesiger werden.

Geit




[ Dieser Beitrag wurde von geit am 15.04.2007 um 13:54 Uhr geändert. ]
 
geit   [Ex-Mitglied]

08.04.2007, 12:57 Uhr

[ - Direktlink - ]
Thema: AREXX Open Window auf Ambient
Brett: MorphOS

Zitat:
Original von AmigaHarry:
@geit:

Danke, genau was ich gesucht habe....

Sag mal, wo findet man alle diese Infos? Ich kenne nur das Pegasos-Book.....


Naja, den "Do" Befehl habe zufällig ich geschrieben! ;)

Ansonsten gibt es IMHO keine Sammlung von Tipps. Vielleicht eine Idee der Benutzer mal eine Art Anleitung zu schreiben, die wir dann Ambient beilegen können.

Geit
 
geit   [Ex-Mitglied]

04.03.2007, 23:27 Uhr

[ - Direktlink - ]
Thema: AREXX Open Window auf Ambient
Brett: MorphOS

@AmigaHarry:

Ist zwar kein Arexx, aber auch eine andere Möglichkeit, die man nutzen kann

do work:

öffnet Laufwerk work:

do ""

öffnet das aktuelle Verzeichnis.

Geit



 
geit   [Ex-Mitglied]

13.02.2007, 13:09 Uhr

[ - Direktlink - ]
Thema: Beispiel zu Datenübertragung via Netzwerk
Brett: Programmierung

Zitat:
Zitat:
Jedes der Programme verschickt ermittelte Daten/Kommandos an das andere.

Da die Daten allerdings zur Laufzeit ermittelt werden, ergeben sich daraus "Pakete". Jedes Paket wird mit
send() verschickt und daten via recv() empfangen. Wenn ich jetzt 5 mal send mit einem paket anwende, dann kommen auf dem anderen Rechner 5 Pakete an, die aber durcheinander sind.


Du solltest Dich erst einmal entscheiden, was Du nun wirklich willst, TCP oder Pakete. Es geht nur eins von beiden.


Ob ich die empfangenen Dateien wieder in Packete teile ist doch schnuppe. Ich will nur Daten verschicken und am anderen Ende in einem
zusammenhängenden Puffer empfangen. Also wie bei einer seriellen übertragung.

Aber wenn die Daten auf dem Quellrechner nicht schnell genug kommen, dann kommen hinten am zweiten Rechner mehrere Packete in unterschiedlicher Reihenfolge an. Das kann ich anhand der Daten im Puffer lesen.

Zitat:
Wenn Du das geschafft hast, kannst Du Dich auch entscheiden, ob Du die Funktionen für TCP oder für Pakete verwendest.
Warum so schroff? Vielleicht könntest du mal sagen, welche Funktionen das sind? Send() und Recv() scheinen es jedenfalls nicht zu sein.

Zitat:
Zitat:
Wenn ich es richig Verstanden habe, sind deine "Packete" bereits in der "Anwender Schicht".
Das hast Du nicht richtig verstanden.

Doch hat er. Der serielle Puffer wird von meinem Programm in Pakete zerlegt, die dann IM Rechner als solche behandelt werden.

Mein Problem ist wie bekomme ich das hin, das die Daten hintereinander
reinkommen und sich nicht auf der Datenautobahn überholen. Das passiert nämlich
derzeit. Ich verschicke schnell hintereinander zwei meiner Packete (Also zweimal
eine beliebige Datenmenge) einzeln mit send() und sie kommen richtig und mit
einem recv() auf der anderen Seite an. Dann kommen nochmal zwei Pakete (also
wieder zwei beliebige Datenmengen) die wieder einzeln abgeschickt werden und die
kommen verkehrt an, weil die gegenstelle zwei mal recv() aufruft.

Was muß ich an meinem Programm ändern, damit ich eine übertragung erzeuge, die
einer seriellen Verbindung gleicht.

Geit
 
geit   [Ex-Mitglied]

08.02.2007, 11:11 Uhr

[ - Direktlink - ]
Thema: Beispiel zu Datenübertragung via Netzwerk
Brett: Programmierung


Ich glaube du hast mich da leicht missverstanden.

Obige Funktionen laufen auf zwei Rechnern. (Amithlon und MOS)

Jedes der Programme verschickt ermittelte Daten/Kommandos an das andere.

Da die Daten allerdings zur Laufzeit ermittelt werden, ergeben sich daraus "Pakete". Jedes Paket wird mit
send() verschickt und daten via recv() empfangen. Wenn ich jetzt 5 mal send mit einem paket anwende, dann kommen auf dem anderen Rechner 5 Pakete an, die aber durcheinander sind. Teilweise bekomme ich 2 oder 3 zusammenhängend (STREAM), aber teilweise werden die einzeln angeliefert.

So kommt das zweite mit send() verschickte Paket z.B. auch als 5. an.

Das passiert mit den Routinen die oben abgebildet sind.

Das ermitteln der einzelnen Pakete in dem Strom ist kein Problem. Da ich das ganze eventuell auch seriell machen will, muß ich mir das sowieso offen halten.

Lösungen und Tips sind willkommen!

Geit
 
geit   [Ex-Mitglied]

07.02.2007, 12:16 Uhr

[ - Direktlink - ]
Thema: Beispiel zu Datenübertragung via Netzwerk
Brett: Programmierung


So ich hab mal was zusammengebastelt. Es funktioniert auch Teilweise.

Zur erklärtung. TCP_Init() wird beim Programmstart ausgeführt. TCP_Open *in* der Programmschleife, damit z.B. später in der WBStart keine Probleme auftreten, wenn es die bsdsocket.library noch nicht gibt. Daher kann die Funktion mehrfach gestartet werden.

Das die Packete nicht in Sendereihenfolge eintreffen, ist wohl Netzwerk bedingt und ich komme um eine Sortierung nicht rum. Oder sehe ich das falsch?

IMHO können keine Packete verloren gehen, sondern nur auf sich warten lassen. Richtig?

Manchmal passiert es, dass ich einen Neustart des NetStacks machen muß, damit ich ohne Fehler wieder was einhängen kann, also scheint meine Routine nicht ganz optimal zu sein. ;)

Kommentare, Anmerkungen sind willkommen. so ganz blick ich das immer noch nicht.

Geit
C code:
/* TCP stuff */

int                tcp_socketclientinfd;
struct sockaddr_in tcp_socketclient;
ULONG              tcp_sizeclient;

int                tcp_socketserverfd;
struct sockaddr_in tcp_socketserver;

int                tcp_socketclientoutfd;
struct sockaddr_in tcp_socketclientout;

BOOL               tcp_pipein;
BOOL               tcp_pipeout;


struct List paketlist;
struct TCPMessage *lasttcpmsg;

#define SERIALBUFFER_SIZEOF 8192

BYTE  serialbuffer[ SERIALBUFFER_SIZEOF ];
ULONG serialindex;


/* TCP Init */

void TCP_Init( void )
{
	List_Init( &paketlist );

	tcp_socketserverfd = -1;
	tcp_socketclientoutfd  = -1;

}

/* TCP Open */

ULONG TCP_Open(void)
{
ULONG arg;

	debug("TCP: setup...\n");
	if( !SocketBase ) {
		SocketBase = (struct Library *) OpenLibrary( "bsdsocket.library", 4);
		debug("tried to open bsdsocket.library\n");
	}
	if( SocketBase ) {

/* init incoming data pipe if needed */

		if( !tcp_pipein ) {
			if( -1 != (tcp_socketserverfd = socket( AF_INET, SOCK_STREAM, 0)) ) {

				/* fill sockaddr_in and bind socket to local port */

				tcp_socketserver.sin_family      = AF_INET;
				tcp_socketserver.sin_port        = htons(VKM_PORT);
				tcp_socketserver.sin_addr.s_addr = htonl(INADDR_ANY);
				//memset(&(tcp_socketserver.sin_zero), '\0', 8);
				arg = 1;
				if( -1 != IoctlSocket( tcp_socketserverfd, FIONBIO, &arg) ) {
					debug("TCP: in socket non blocking enabled\n");
					if( -1 != bind( tcp_socketserverfd, (struct sockaddr *) &tcp_socketserver, sizeof(struct sockaddr) ) ) {
						debug("TCP: in socket bond to port\n");
						if( -1 != listen( tcp_socketserverfd, 10) ) {
							debug("TCP: in socket listening to port - ready for action\n");
							tcp_pipein = TRUE;
						}
					}
				}
			}
			if( !tcp_pipein && tcp_socketserverfd != -1 ) { /* shut down pipe due error */
				debug("TCP: Closing in socket due fail\n");
				CloseSocket( tcp_socketserverfd );
				tcp_socketserverfd = -1;
			}
		}

/* init outgoing data pipe */

		if( !tcp_pipeout && readargs_array[ARG_IP ] ) {
			if( -1 != (tcp_socketclientoutfd = socket(AF_INET, SOCK_STREAM, 0)) ) {
				/* fill sockaddr_in struct for connection */
				tcp_socketclientout.sin_family      = AF_INET;
				tcp_socketclientout.sin_port        = htons( VKM_PORT);
				tcp_socketclientout.sin_addr.s_addr = inet_addr( (STRPTR) readargs_array[ARG_IP ]);
				//memset(&(tcp_socketfddest.sin_zero), '\0', 8);
				if( -1 != connect( tcp_socketclientoutfd, (struct sockaddr *) &tcp_socketclientout, sizeof(struct sockaddr)) ) {
					debug("TCP: out socket connected - ready for action\n");
					tcp_pipeout = TRUE;
				}
			}
			if( !tcp_pipeout && tcp_socketclientoutfd  != -1 ) { /* shut down pipe due error */
				debug("TCP: Closing in socket due fail\n");
				CloseSocket( tcp_socketclientoutfd );
				tcp_socketclientoutfd = -1;
			}
		}
	}
	debug("TCP: setup done\n");
return( 0 );
}

/* TCP_Close */

void TCP_Close(void)
{
struct TCPMessage *tcpmsg;

/* tcp */

	if( tcp_pipein ) {
		CloseSocket( tcp_socketserverfd );
	}
	if( tcp_pipeout ) {
		CloseSocket( tcp_socketclientoutfd );
	}
	if( SocketBase ) {
		CloseLibrary( (struct Library *) SocketBase );
		SocketBase = NULL;
	}

/* free used memory */

	if( paketlist.lh_Head ) {

		while( (tcpmsg = (APTR) paketlist.lh_Head)->tcp_Node.ln_Succ ) {
			TCP_UnqeuePaket ( tcpmsg );
		}
	}

}

/* TCP_TransferHandle */

void TCP_TransferHandle( void )
{
ULONG num;

	if( tcp_pipeout ) {
		if( (lasttcpmsg = (APTR) paketlist.lh_Head)->tcp_Node.ln_Succ ) {
			num = send( tcp_socketclientoutfd, &lasttcpmsg->tcp_Command, lasttcpmsg->tcp_Command.cmd_Size, 0 );
			if( num != -1 && num != 0 ) {
				TCP_UnqeuePaket( lasttcpmsg ); /* remove packet from packet list */
				debug("TCP: Send %ld Bytes\n", num);
			}
		}
	}
	if( tcp_pipein ) {
		if( !tcp_socketclientinfd || tcp_socketclientinfd == -1 ) {
			tcp_socketclientinfd = accept( tcp_socketserverfd, (struct sockaddr *)&tcp_socketclient, &tcp_sizeclient);
			//debug("accept: %ld\n",tcp_socketclientinfd );
		}
		if( SERIALBUFFER_SIZEOF - serialindex ) {
			if( -1 != (num = recv( tcp_socketclientinfd, &serialbuffer[ serialindex ], SERIALBUFFER_SIZEOF - serialindex , 0) )) {
#if DEBUG
				if( num ) {
					debug("TCP: got %ld Bytes: %80lh\n", num, &serialbuffer[ serialindex ]);
				}
#endif
				serialindex += num;
			}
		}
		//TCP_HandleBuffer(); /* read and proccess packets from cache */
	}
}




[ Dieser Beitrag wurde von geit am 07.02.2007 um 12:20 Uhr geändert. ]
 
geit   [Ex-Mitglied]

02.02.2007, 22:54 Uhr

[ - Direktlink - ]
Thema: locale: FormatString()
Brett: Programmierung

@Ralf27:


Hier das Beispiel, aus dem SDI_misc example. Ist zwar für DoRawFmt von Exec, aber im Prinzip ist es das Selbe.

Hier gibt es den ganzen SDI Kram. Der Vorteil ist, dass die komplizierten Hooks
etc mit SDI, durch einfach Macros ersetzt werden und das ganze auch Compiler und
System unabhängig ist.

http://sourceforge.net/projects/sditools

code:
#include <proto/exec.h>
#include <proto/utility.h>

#include <stdarg.h>
#include <stdio.h>
#include <ctype.h>

#include "SDI_misc.h"


/*
**
**This structure keeps our internal sprintf vars during RawDoFmt()
**
*/

struct SPrintfStream
{
    char    *Target;
    ULONG    TargetSize;    /* Obsolete in this example, but useful when
                               dealing with size limited streams */
};

/*
** SPrintf_DoChar
**
** The following function is just an example where we use the object
** for composing some minor text. Do you see how easy it is to use and
** how great it is to use SDI_misc.h to automatically keep your sources
** compatible to all common AmigaOS platforms?
**
*/

PUTCHARPROTO( SPrintf_DoChar, char c, struct SPrintfStream *s  )
{
    *(s->Target++) = c;
}

/*
**
** SPrintf
**
** Here you can see how the function is used by the ENTRY() function.
**
*/

ULONG SPrintf( char *format, char *target, ULONG *args );
ULONG SPrintf( char *format, char *target, ULONG *args )
{
struct SPrintfStream s;

    s.Target  = target;

    RawDoFmt( format, args, ENTRY( SPrintf_DoChar ), &s);

    return( s.Target - target );
}

/*
**
** The main entry point
**
*/

int main(void)
{
    char buf[0x80]; /* storage for keeping the SPrintf result string */
    ULONG args[2];  /* storage for keeping the SPrintf arguments */

    args[0] = (ULONG) "result";
    args[1] = (ULONG) "PUTCHARPROTO macro";

    SPrintf("I am the %s of using SPrintf() with the new %s!", buf, args);

    printf("%s\n", buf); /* just a simple printf to output and add the \n */

return( 0);
}


Geit
 
geit   [Ex-Mitglied]

02.02.2007, 14:07 Uhr

[ - Direktlink - ]
Thema: Beispiel zu Datenübertragung via Netzwerk
Brett: Programmierung

Gibt es ein einfaches Beispiel, wie man via bsdsocket.library Daten übertragen kann?

Ich möchte ein kleines Programm schreiben, das über einen Port kleine Datenpakete hin und her schiebt. Das Programm soll dabei auf beiden Rechnern zum Einsatz kommen.

Bei der Funktionsvielfalt der bsdsocket.library und meinen beschränkten Netzwerkkenntnissen blick ich das nicht so ganz. :)

TCP: oder externe Libraries möchte ich nicht benutzen.

Geit
 
geit   [Ex-Mitglied]

26.01.2007, 11:35 Uhr

[ - Direktlink - ]
Thema: vbcc Linker-Bibliothek erstellen?
Brett: Programmierung

@whose:

Also ich baue meine VBCC Objekte auch mit "ar -q" zu einer Lib zusammen.

Das mit dem Hunkformat und join wußte ich vor einem Jahr oder so auch noch nicht. Ich hab es auch temporär in Skripten benutzt.

Bei ELF Dateien kommt man um ar aber nicht herum.

Geit
 
geit   [Ex-Mitglied]

17.01.2007, 00:39 Uhr

[ - Direktlink - ]
Thema: SDCMD_QUERY-io_Actual
Brett: Programmierung

Zitat:
Original von MaikG:

>Nein, eben nicht. Du startest mit SendIO einen ReadRequest
>von 1 Byte. Der SendIO() kehrt *sofort* zurück, darum machen wir
>das ja. DoIO() wartet gnadenlos bis zum Ende und wenn jemand das
>Kabel zieht ist das Programm tod.

Ja, SendIO, aber wie warte ich auf das SendIO denn?

Fenster ist so:

code:
junk&= xWait&(1& << PEEKB(PEEKL(win&+UserPort%)+mp_SigBit%))




Genauso. Du hast ja den Port für den IOrequest allokiert. Den benutzt du genauso.

code:
junk&= xWait&(1& << PEEKB(PEEKL(win&+UserPort%)+mp_SigBit%) | 1& << PEEKB(PEEKL(port%)+mp_SigBit%))


Ist jetzt warscheinlich falsch, aber dieses Basic &% Zeugs versteh ich nicht wirklich. Du verschiebst eine
1 um die Signalnummer aus dem Port vom IORequest. Diese Maske oderst du z.B. zu dem Wert , den du aus dem
Fensterport emittelst. Dann wartet der Wait() auf beide Signale. Mit dem junk Feld und dem Masken Wert kannst
du dann geziehlt Abfragen, ob eines oder mehere der Signale aktiv sind und entsprechend handeln.


Zitat:
Original von MaikG:

>Nein, ich meine nicht einen Delay von Sekunden oder so, sondern
>einen Delay(1). Der verhindert, das der Task 100% Systemlast
>bekommt. Für Testzwecke zu empfehlen, aber für die finale Benutzung
>ehr nicht.

Ich habe Delay 1, 5 und 10 Probiert, immer das selbe.
Dann hab ich die Taskpriorität des Programms auf -1 und -5 geändert,
nicht erfolgreich.
Immerhin konnte ich durch das abschalten aller Caches das ganze
auf meinem 68060 System reproduzieren.


Sollte nicht sein. Wo hast du den eingebaut. Der sollte in "Zeile 10" oder direkt vor dem Goto nach 10 liegen, um bei jedem Schleifenumlauf zu wirken. Wie gesagt diese Lösung ist nicht perfekt und tuagt allenfalls für Testzwecke (wenn man keinen timer öffnen will).

Geit
 
geit   [Ex-Mitglied]

16.01.2007, 22:42 Uhr

[ - Direktlink - ]
Thema: SDCMD_QUERY-io_Actual
Brett: Programmierung

Zitat:
Original von MaikG:

>Einfach gesagt, mit SDCMD_Query fragt man nach der Anzahl der *NOCH* im Puffer verbliebenen Daten *NACH* einem CMD_READ Event.
Wenn jetzt aber 0 Bytes ankommen, weil meinetwegen einer das
kabelrauszieht hängt das auch.


Nein, eben nicht. Du startest mit SendIO einen ReadRequest von 1 Byte. Der SendIO() kehrt *sofort* zurück, darum machen wir das ja. DoIO() wartet gnadenlos bis zum Ende und wenn jemand das Kabel zieht ist das Programm tod.

Ob jemand das Kabel sieht oder nicht ist hier egal. Alles was du braucht ist ein Timer, den du zusätzlich vor dem Transfer startest und mit dem gleichen Wait() abfragst. Das habe ich mit dem Control-C oben angedeutet. Du kannst den Kram zu jederzeit abbrechen mit einem Timer würde dieses Abbrechen automatisch nach einiger Zeit passieren.

Wenn der Request ageschlossen ist und SDCMD_Query 200 Bytes ausgibt, dann ist ein CMD_READ über 200 Bytes sicher und zwar egal ob jemand ein Kabel zieht oder nicht. Die Daten sind ja schon im Rechner angekommen.

Zitat:
Original von MaikG:

Ja, aber nehmen wir an ich mache ein Delay und grade in der
Zeit läuft der Puffer voll, ist doch dann das selbe.


Nein, ich meine nicht einen Delay von Sekunden oder so, sondern einen Delay(1). Der verhindert, das der Task 100% Systemlast bekommt. Für Testzwecke zu empfehlen, aber für die finale Benutzung ehr nicht.

Geit
 
geit   [Ex-Mitglied]

16.01.2007, 18:05 Uhr

[ - Direktlink - ]
Thema: SDCMD_QUERY-io_Actual
Brett: Programmierung

Ich schätze mal der Grund warum Du Probleme auf dem 020 bekommst ist das Polling, das Du durch den ständigen Query erzeugst. Dein Task schluckt die Rechenzeit und wenn der Devicetask mal dran kommt, ist der Buffer voll.

Du solltest, wenn du schon eine auf query basierende Methode verwendest einen Timerwait oder Delay() durchführen.

Generell ist folgendes zu bevorzugen, wenn man nicht warten will. (abstraiert)

code:
do{

 if( CheckIO() ) {
  SendIO( CMD_READ, Length 1 );
 }

 sigs = Wait( 1<<portsignal | SIGBREAKF_CTRLC );

 if( sigs & (1<<portsignal) ) {
  if( CheckIO() ) {
   DoIO( SDCMD_QUERY );
   if( actual ) {
    DoIO( CMD_READ, Length actual);
    total += actual;
   }
  }
 }
} until( total >= wanted );


Ggf. natürlich nicht all actual bytes lesen, sondern nur noch die fehlenden Bytes.

Es wird gewartet, bis 1 Byte gelesen wurde und dann nachgesehen, ob weitere Bytes anliegen, die man dann abholt. Wenn man sicher ist, dass mehrere Daten kommen, kann man natürlich statt einem Byte auch 100 oder 1000 lesen.

Der Query sollte nur verwendet werden, um nicht mehr Daten zu lesen, als bereits vorhanden sind.

Dinge wie

While( actual < 100 ) { DoIO( SDCMD_QUERY ); }

sollte man natürlich vermeiden, weil man eine Endlosschleife mit 100% Tasklast verursacht, bis alle Daten komplett eintreffen. Selbst mit einem Delay() dazwischen ist das nicht so clever.

Mit dem asyncronen Lesen von einem Byte verhindert man, das man direkt in DoIO() wartet und zweitens bekommt man einen Trigger, der den eigenen Task bei eintreffen von Daten aufweckt.

Einfach gesagt, mit SDCMD_Query fragt man nach der Anzahl der *NOCH* im Puffer verbliebenen Daten *NACH* einem CMD_READ Event.

Geit
 
geit   [Ex-Mitglied]

27.12.2006, 22:03 Uhr

[ - Direktlink - ]
Thema: SAS-C und GST
Brett: Programmierung


Also ich muß mich leider meinem Vorredner anschließen. Der SASC ist nun wirklich sehr veraltet und wird nicht weiter entwickelt.

Wenn du einen einfach zu installierenden und zu benutzenden Kompiler suchst, dann installier VBCC.

Als Bonbon kannst du Deine Programme gleich auch nativ für andere Platformen übersetzen.

Geit
 
geit   [Ex-Mitglied]

26.11.2006, 15:19 Uhr

[ - Direktlink - ]
Thema: TD_FORMAT "repariert" Disketten?
Brett: Programmierung

Bei entsprechender Lagerung sind die Disketten noch in Ordnung. Die Daten gehen verloren, weil die Magnetisierung der Scheiben nachläßt.

Wenn du jetzt die Disketten neu schreibst, wird diese Magnetisierung aufgefrischt und die Disketten funktionieren wieder.

TD_Write und TD_Format unterscheiden sich auch technisch nicht wirklich.

Das Laufwerk beschreibt immer einen kompletten Track. Egal ob du 512 Bytes oder 4KB schreibst. Es wird immer der komplette Track neu formatiert.

TD_Write ließt den Track ein, ersetzt die neuen Bytes und schreibt den Track wieder komplett. (IMHO nutzt es dafür dann auch TD_FORMAT)
TD_Format schreibt einen kompletten Track auf die Schreibe.

Der Grund ist einfach. Laufwerke drehen nicht gleich schnell und sie reagieren nicht gleich schnell. Daher kann man nicht einen Sektor direkt ansprechen.

Es werden daher immer mehr Daten auf die Umdrehung geschrieben als draufpassen. Das geschieht durch eine Lücke vor den eigentlichen Sektoren. Diese Lücke wird wird dann am Ende des Tracks teilweise wieder mit Nutzdaten überschrieben. Würde man das erste Byte auf einem Track markieren und dann den Track lesen und wieder schreiben, würde dieses erste Byte komplett woanders auf der Scheibe liegen. Der Anfang eines Track wird durch eine Synckennung ermittelt. Das ist auch der Grund, warum man die Lücke schreiben muß. Es könnte sich ja zufällig hinter einem Track noch die alte Sync-Markierung finden und so hätte man plötzlich 2 Anfänge auf dem selben Track.

Einige Trackloader machen sich diese Eigenschaften zu nutze und schreiben längere Spuren um mehr Daten pro Track zu schreiben. Es gibt auch einige Treiber, die es ermöglichen auf eine Amiga Diskette 920 umd mehr KB unter zu bringen.

Geit


[ Dieser Beitrag wurde von geit am 26.11.2006 um 15:26 Uhr geändert. ]
 
geit   [Ex-Mitglied]

22.11.2006, 23:52 Uhr

[ - Direktlink - ]
Thema: Maske für BltMaskBitMapRastPort() per Datatype laden...
Brett: Programmierung

Ich hab das Problem "umgangen" indem ich via PPaint jedes Bild auf 2 Farben reduziert habe und dieses Maskenbild als eigene Bitmap via Datentyp eingeladen habe und damit den Blit durchgeführt.

Die Maske kann man sehr einfach erstellen, in dem man die Transparente Farbe via PPaint-Maske blockiert und dann den Bildschirm füllt. Jetzt hat man nur noch zwei Farben und kann gefahrlos die Farbreduzierung nutzen.

Das Blitten funktioniert aber auch nicht mit MOS1.4.x. Erst mit MOS1.5 geht es. Unter Amithlon OS3.9 geht es auch.

Geit

[ Dieser Beitrag wurde von geit am 22.11.2006 um 23:53 Uhr geändert. ]
 
geit   [Ex-Mitglied]

27.10.2006, 23:59 Uhr

[ - Direktlink - ]
Thema: FryingPan auf Deutsch?
Brett: Amiga, AmigaOS 4

@tploetz:

Das Problem scheint in Frying Pan selbst zu liegen.

Keine Ahnung warum und wieso, aber er mag die deutschen Kataloge nicht. Sie sind in Ordnung und müßten funktionieren.

Unter MorphOS tun sie das auch, aber unter AmigaOS 3.9 läuft die *selbe* installation nicht.

Geit
 
geit   [Ex-Mitglied]

16.09.2006, 13:35 Uhr

[ - Direktlink - ]
Thema: MUI Cycle Object: Einträge hinzufügen
Brett: Programmierung

Zitat:
Original von Holger:
Zitat:
Original von geit:
Andersherum sollte eine Checkbox z.B. niemals eine zusätzliche Option zu einem Cycle hinzufügen oder entfernen, weil das verwirrt und der Benutzer die neue Option schlicht nicht findet.

Ich denke, da kann man die gleiche Ausnahme anbringen, die Du vorher genannt hast. Wenn es nur genau eine neue Option gibt, und diese nicht nur hinzugefügt, sondern auch sofort ausgewählt wird, ist sie auch sichtbar.

Das stimmt natürlich.

Kritisch wird es in jedem Fall beim Weglassen.

Bei einer Listenersetzenden Funktion des Cycles hat der Nutzer meistens "entfernen" oder so gedrückt, aber bei dem CheckBox->Cycle Beispiel hat man nicht nur das Problem, das die Option unsichtbar entfernt wird, sondern auch noch, dass das Programm eine Option für den Benutzer wählen muß, wenn die zu entfernende Option gerade angewählt war.

Generell sollte man sehr vorsichtig sein, um nicht "unverständlich" zu werden.

Wenn man z.B. aus dem Cycle "Tiere", den "Elefanten" rausnimmt, dann kann man im Cycle "Besonderheiten" auch den "Rüssel" rausnehmen, wenn in "Tier" nicht noch z.b. "Ameisenbär" drin steht. Den Zusammenhang kennt eben jeder. :)
Sobald man aber exotischere Tiere nimmt, die man nicht unbedingt genau kennt, oder die einen sogenannten Rüssel haben, der aber nicht im Ansatz dem eines Elefanten ähnelt, wird es wieder kompliziert.

Geit
 
geit   [Ex-Mitglied]

15.09.2006, 12:10 Uhr

[ - Direktlink - ]
Thema: MUI Cycle Object: Einträge hinzufügen
Brett: Programmierung

Danke auch von meiner Seite.

Ich hatte gerade genau das selbe Problem mit dem Karteneditor von ValiantVision.

Hat mir viel Zeit und Nachdenken erspart. Danke!

Anmerken sollte man vielleicht noch, dass es laut Style Guide nicht gemacht werden sollte, weil man für den Benutzer unsichtbar neue Optionen hinzufügt.

IMHO kann man aber die Ausnahme geltend machen, dass man eine kleine Liste hat und nur bei "Neu" durch den Benutzer einen Eintrag zufügt und auch gleich auf diesen Eintrag wechselt.

Andersherum sollte eine Checkbox z.B. niemals eine zusätzliche Option zu einem Cycle hinzufügen oder entfernen, weil das verwirrt und der Benutzer die neue Option schlicht nicht findet.

Geit

[ Dieser Beitrag wurde von geit am 15.09.2006 um 12:11 Uhr geändert. ]
 
geit   [Ex-Mitglied]

10.08.2006, 13:11 Uhr

[ - Direktlink - ]
Thema: Astra Sat Verschlüsselung bei den FreeFernsehen
Brett: Get a Life


Bin gerade beim Spiegel darüber gestolpert:

http://www.spiegel.de/netzwelt/technologie/0,1518,429962,00.html

Geit


 
geit   [Ex-Mitglied]

09.08.2006, 21:36 Uhr

[ - Direktlink - ]
Thema: 911 Loose Change
Brett: Get a Life

Zitat:
Original von Maja:
> Nicht reisserisch, sondern sachlich

Sachlich? Extrem schnelle Schnitte, emotionalisierende Dauermusikuntermalung, streckenweise unterlegt mit montonem Monolog in Grabesredemanier, schicksalsschwanger und klagend. Das ist alles anderes als sachlich.

> und meistens mit einer Frage an die offiziellen Stellen.

Fragen, die nicht wirklich neu sind. Wenn soetwas passiert, bleiben immer Fragen offen. Das bedeutet nicht, dass die Antwort auf jede Frage den Erwartungen entspricht.

Ob es so sinnvoll ist, mit einer Fake-Doku Antworten auf Fragen erzwingen zu wollen? Das hat schon im Fall J.F.K nicht zum Ziel geführt. Und auch da war zu keiner Zeit klar, ob dieses Ziel je existierte; ob der Mord an J.F.K. von Regierungsangehörigen und/oder Geheimdienst inszeniert wurde. Auch dort war das immer nur eine von mehreren Theorien zum Geschehen.

So wie die Theorie, dass Jonnes Paul I frühzeitiges Ableben nicht ganz natürlicher Natur war, da er vier Wochen zuvor bei Amtsantritt erklärte, den Zölibat abschaffen zu wollen.


Also entweder denkt mein Gehirn zu schnell, oder die "Second Edition" ist in dem Sinne anders, als die Version die du kennst. ;)

Ansonsten kann ich nichts "Fake" daran finden. Die Bilder haben wir alle schon gesehen und nur weil jemand Details offenlegt, die einem bislang nicht aufgefallen sind, heißt das noch nicht das es Fake ist.

Man kann auch mit einer gewissen Skepsis an die Sache rangehen, sich aber diversen Fakten nicht verschließen.

Ob ich nun mit Trompetengesang die Lottozahlen verkünde, oder ohne. Es bleiben Lottozahlen!

Geit

[ Dieser Beitrag wurde von geit am 09.08.2006 um 21:39 Uhr geändert. ]
 
geit   [Ex-Mitglied]

09.08.2006, 17:38 Uhr

[ - Direktlink - ]
Thema: 911 Loose Change
Brett: Get a Life

Ich hab mir gerade den Film "911 Loose Change" angesehen und muß sagen, der ist gleichermaßen aufwühlend wie beängstigend.

Wer ihn nicht kennt, er ist frei im Netz runterzuladen und mittlerweile (angeblich) auch auf DVD erhältlich.

In dem Film geht es um die Anschläge auf das World Trade Center, aber anders als andere Filme wurde hier nur das öffentlich für jederman zugängliche Material zusammengeschnitten und anschaulich kommentiert.

Es werden dutzende von Fragen gestellt, auf die es augenscheinlich keine logische Antwort gibt, wenn es sich wirklich um einen Terroranschlag gehandelt hat.

Warum gab es nur eine Hand voll Flugzeugtrümmer am Pentagon?
Warum passen diese Trümmer nicht zu einem Linienjet, sondern zu einem Militärflugzeug?
Wie kann ein Jet 5 Laternen rausreißen, ohne die Flügel oder Teile zu verlieren, wenn eine einzelne Laterne bei einem anderen Unglück einen ganzen Flügel abgerissen hat?
Wieso sieht man auf den Bildern des Pentagons nur ein kleines Loch im Gebäude, durch das selbst das Flugzeug ohne Flügel nicht gepaßt hätte?
Wieso sieht man auf dem Rasen des Pentagons schon Tage vor den Attentaten die genaue Flugbahn des Jets?
Warum werden 5 Bilder von den Sicherheitskameras veröffentlicht, aber nicht das ganze Material?
Wie können 4 Flight-Recoder auf dem härtesten Material den Einschlag in das WTC nicht überstehen, wenn ein Ausweis eines der Terroristen aus Papier unbeschadet in den Trümmern gefunden wird?
Wieso sieht man Explosionen 3-4 Stockwerke unterhalb des eigentlichen Einsturzes?
Wie kann das Material des WTC nach 55 Minuten schmelzen, wenn es laut Hersteller mehrere Stunden bei fast doppelter Hitze gedauert hätte?
Warum gibt es keine Trümmer von Flug 93?

Klingt interessant? Keine Frage, aber das war nur die Spitze.

Fast 90 Minuten lang werden hier die Geschenisse von anderer Seite beleuchtet. Nicht reisserisch, sondern sachlich und meistens mit einer Frage an die offiziellen Stellen.

Wer den nicht gesehen hat, kann nicht mitreden!

Beide Daumen hoch für diesen Film!

http://video.google.de/videoplay?docid=-1272980089639960023&q=loose+change

Geit



[ Dieser Beitrag wurde von geit am 09.08.2006 um 18:01 Uhr geändert. ]
 
geit   [Ex-Mitglied]

09.08.2006, 17:33 Uhr

[ - Direktlink - ]
Thema: Astra Sat Verschlüsselung bei den FreeFernsehen
Brett: Get a Life

@malte2:

Ich auch, aber rechtlich ist es so. ;)

Geit

 
 
Erste 2 3 4 5 6 -7- 8 9 10 11 12 Ergebnisse der Suche: 332 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.