API-Unterschiede TF5k - TMS

[FireBird]

Hi,

ich eröffne hier einen Thread, in dem die Unterschiede zwischen TF5000- und TMS-TAP-API bzw. Entwicklungsumgebung besprochen werden können. Bei interessanten Erkenntnissen komme ich gerne auf Pauls Angebot zurück, diese in das Wiki zu übernehmen.

MfG. Alex

[FireBird]

Ich mache auch gleich den Anfang mit einem Tipp, den ich bei Filer hätte brauche können:

Code: Alles auswählen

TAP_Osd_SetTransparency(word rgn, char rt);

ist in der TMS-Version der tap.h nicht korrekt deklariert. Im Gegensatz zur 5k-Version, ist im ersten Parameter nicht mehr die Region, sondern die Zeichenebene anzugeben. Die möglichen Konstanten sind in der tap.h definiert.

Code: Alles auswählen

#define BASE_PLANE  0   // osd base, ttx
#define SUBT_PLANE  1   // subtitle
#define TAP_PLANE   2   // tap

Im größten Teil der Fälle wird also TAP_PLANE im ersten Parameter stehen müssen.

[xyzzyx]

• Warnung vor der Verwendung der Variable "wait":
  vermutlich gibt es einen Namenskonflikt beim TMS bzgl. Variable "wait"
  wird scheinbar intern vom TMS global verwendet
  kann zu falschen Werten führen
  wait steht immer auf einem festen Wert, bei Test-Ausgabe mit %08X war es "3C1C0001"
  Zuweisung von GetTick zu wait kann zu Absturz führen

• Stichwort Dokufehler in TMS API Doku v0.1 (1):
  beim TMS-API werden sehr wohl Timer-Funktionen unterstützt (siehe TimerList.c Sample), die Beschreibung fehlt nur in der Doku zur TMS-API

to be continued soon

[macfan]

Ein Problem, das Erdnussnase zu schaffen machte:
Farben sind beim TMS dword, beim 5k word.

Gruß, Horst

[FireBird]

[quote="macfan"]Farben sind beim TMS dword, beim 5k word.[/quote]
Richtig. Also alle, die das ARGB-Macro verwenden und es mit Werten zwischen 0 und 31 füttern, erhalten ziemlich dunkle Farben, da beim TMS jede Grundfarbe 8 Bit hat und somit bis 255 läuft. Am schnellsten ist die Definition eines eigenen ARGB-Macros, das die übergebenen Werte unauffällig mit 8.22 multipliziert (~ 255/31).

In dem Zusammenhang gleich die Zusatzinfo, dass das Alpha-Flag nicht 1, sondern 255 sein muss, damit nicht transparent gemalt wird. Am besten, man verwendet die in der tap.h deklarierten Konstante TAP_ALPHA.

[xyzzyx]

Auch wenn es sich vielleicht nicht mehr lange lohnt... hoffentlich kommt ja bald eine bessere TMS API... Aber vielleicht könnte Gerti es ja auch als Input nach Korea geben.

Doku-Bugs:

• Stichwort Dokufehler in TMS API Doku v0.1 (2):
  Funktion "int TAP_Channel_ExchangePip(void);" ist in tap.h definiert, fehlt aber in der Doku
  tauscht bei aktiviertem PIP das Haupt- und PiP-Bild (wie SAT-Taste)
  neue Funktion gegenüber TF5k

• Stichwort Dokufehler in TMS API Doku v0.1 (3):
  Funktion "dword TAP_Hdd_FindFirst( TYPE_FolderEntry* file, const char* extension);" ist in tap.h definiert, in der Doku steht fälschlicherweise "dword TAP_Hdd_FindFirst( TYPE_File *file )"
  man kann gleich bei FindFirst auf bestimmte Dateierweiterungen einschränken
  Beispiel:
  "TYPE_FolderEntry file;"
  "totalEntry = TAP_Hdd_FindFirst( &file, "jpg|jpeg");" oder
  "totalEntry = TAP_Hdd_FindFirst( &file, NULL);"
  neue Variable "extension" gegenüber TF5k und file ist beim TMS jetzt vom TYPE_FolderEntry (siehe hdd.h), bei TF5k war es vom TYPE_File

• Stichwort Dokufehler in TMS API Doku v0.1 (4):
  Funktion "dword TAP_Hdd_FindNext( TYPE_FolderEntry* file);" ist in tap.h definiert, in der Doku steht fälschlicherweise "dword TAP_Hdd_FindNext( TYPE_File *file )"
  file ist beim TMS jetzt vom TYPE_FolderEntry (siehe hdd.h), bei TF5k war es vom TYPE_File

• Stichwort Dokufehler in TMS API Doku v0.1 (5):
  Funktion "int TAP_Osd_Zoom( int xzoom, int yzoom );" ist in tap.h definiert, in der Doku fehlt es
  FireBird hat herausgefunden, dass aber kein Coding mehr dahintersteckt
  die Funktion gab es scheinbar mal für TF5k (in TAP.H und Doku), aber für TMS derzeit ohne Coding

• Stichwort Dokufehler in TMS API Doku v0.1 (6):
  Funktion "TYPE_Window TAP_Win_Create(word rgn, dword x, dword y, dword w, dword h, dword maxItem, byte save, byte bScr );" ist in tap.h definiert, in der Doku steht aber die falsche Variante "TYPE_Window TAP_Win_Create( TYPE_Window win, word rgn, dword x, dword y, dword w, dword h, dword maxItem, byte bScr )"
  richtig sind also die Parameter "Region, Pos-x, Pos-y, Breite, Höhe, max. Anzahl der Items, Save, Scrollbar", wobei Save wohl das Hintergrundbild sichern soll, bevor das Fenster gezeichnet wird
  neu gegenüber TF5k ist demnach, dass TYPE_Window jetzt der Rückgabewert und nicht mehr der erste Parameter ist und dass man die max. Anzahl der Items übergeben kann

• Stichwort Dokufehler in TMS API Doku v0.1 (7):
  Funktion "dword TAP_DiffTick(dword oldTick, dword newTick);" ist in tap.h definiert, in der Doku fehlt diese Funktion
  neue Funktion gegenüber TF5k

Jetzt was für die TAP-Portierer oder auch TMS-Neueinsteiger...
Wissenswertes:

• Tastenänderungen/u]
  gegenüber dem TF5k sollte man folgende Tasten für den TMS anpassen
• Steuerkreuz
  von RKEY_VolDown auf RKEY_Left
  von RKEY_VolUp auf RKEY_Right
  von RKEY_ChUp auf RKEY_Up
  von RKEY_ChDown auf RKEY_Down
• fehlende White-Taste in key.h im eigenen Code definieren, falls nötig (ermittelt über KeyRecord Sample)
  #define RKEY_White 0x10049
• rote F1 Taste ist nicht RKEY_F1 sondern RKEY_NewF1 (war aber bei TF5k scheinbar auch schon so)
  #define RKEY_Red RKEY_NewF1
• beim TMS ist die SAT-Taste nicht RKEY_TvSat (0x10022) sondern RKEY_Sat (0x10040), aber RKEY_TvSat (0x10022) gibt es trotzdem und es steht für die "M"-Taste (Scart-Quelle)

• OSD-Synchronisation (ganz wichtig, häufigste Fehlerquelle bei Anzeigeproblemen am TMS):
  in TF5k wurde der OSD-Aufbau scheinbar intern geregelt
  im TMS muss der OSD-Aufbau nach Benutzung von OSD- oder Window-Funktionen manuell mit "TAP_Osd_Sync();" (void TAP_Osd_Sync(void) ) erfolgen!
  wenn man TAP_Osd_Sync benutzt, scheint TAP_Win_Draw nicht wirklich nötig zu sein

• Farbwerte (auch siehe macfan und FireBird):
  in TF5k RGB Werte von 0 bis 31
  im TMS RGB Werte von 0 bis 255
  nachfolgendes ist nur mein Eindruck (wage Erinnerung):
  wobei scheinbar 0 für transparent steht, also RGB(0, 0, 0) = COLOR_None und nicht COLOR_Black, ich vermute mal, COLOR_Black = RGB(1, 1, 1) oder doch 0 aber mit korrekter Belegung des Alpha-Wertes

• Datentypen/u]
  gegenüber dem TF5k achtet scheinbar der TMS-Compiler stärker auf signed- und unsigned-Datentypen bei Vergleichsoperationen
  Lösungen: gleich andere Datentypen für die Variablen (z.B. int statt dword) oder Typumwandlung in der Vergleichsoperation (z.B. "if ( (int) delta > 0)", nur so aus Erinnerung, nicht nochmal getestet)

• <string.h>/u]
  beim TMS-Compiler muss man für die String-Funktionen wie strlen und strcpy die Lib <string.h> als erste bei den Includes stehen haben (noch vor "tap.h"), dagegen scheint die String-Library beim TF5k automatisch eingebunden worden zu sein

• ungenutzte Variablen/u]
  beim TMS-Compiler kann man Compiler-Hinweise auf ungenutzte Variablen durch das TMS-interne Makro "UNUSED(dwParam2);" unterbinden (alternativ die ungenutzten Variablen entfernen)

• häufige TMS-Absturz-Gründe mit TAP API v0.1:
• Array-Zugriffe ohne vorherige Prüfung auf erlaubten Array-Index-Wert
• unter diversen Umständen mit Zeichenketten fester Länge oder Zeichen-Pointern ohne explizite vorherige Initialisierung oder Speicherreservierung (manchmal sollte/muss man auch strcpy statt TAP_SPrint verwenden)
  Beispiel (ohne TAP_MemAlloc würde es zum Absturz führen):
  Items[itemNo] = TAP_MemAlloc(strlen(str) + 1);
  if(Items[itemNo]) strcpy(Items[itemNo], str);
• bei sowas:
  TAP_Win_SetDefaultColor (&g_wndExit);
  TAP_Win_Create (&g_wndExit, g_rgn, 225, 200, 255, 44, FALSE, FALSE);
  TAP_Win_SetTitle (&g_wndExit, PROGRAM_NAME, 0, FNT_Size_1622);
  TAP_Win_AddItem (&g_wndExit, "Exit AutoZapper");
  TAP_Win_AddItem (&g_wndExit, "Cancel");
  TAP_Win_SetSelection (&g_wndExit, 1);
• geändert auf (&-Zeichen entfernt, war "Adresse von"):
  TAP_Win_SetDefaultColor (g_wndExit);
  g_wndExit = TAP_Win_Create (g_rgn, 225, 200, 255, 44, 2, FALSE, FALSE);
  TAP_Win_SetTitle (g_wndExit, PROGRAM_NAME, 0, FNT_Size_1622);
  TAP_Win_AddItem (g_wndExit, "Exit AutoZapper");
  TAP_Win_AddItem (g_wndExit, "Cancel");
  TAP_Win_SetSelection (g_wndExit, 1);

• häufige Ursachen für falsche Werte (evtl. auch Abstürze) mit TMS TAP API v0.1:
• Variable "wait" (siehe oben)
• Demux-Filter ist noch buggy bzw. unzureichend für PES-Stream
• bei sowas (Pointerumwandlung für Teilfeldzugriff oder Datentypvergrößerung):
  #define NOW *(dword*)&myDate.mjd
  ...
  TAP_ExtractMjd( *(word*)&rr.recStart, &myDate.year, &myDate.month, &myDate.day, &myDate.weekDay );
  ...
  #define BYTE(x,y) ((byte*)&rr.x)[y] //bei dword Feldern im Format mjd (word), Stunde (byte), Minute (byte)
• geändert auf:
  #define NOW DATE(myDate.mjd, myDate.hour, myDate.min) //DATE aus FireBird Lib
  ...
  TAP_ExtractMjd( MJD(rr.recStart), &myDate.year, &myDate.month, &myDate.day, &myDate.weekDay ); //MJD aus FireBird Lib
  ...
  //BYTE-Makro umgangen mit HOUR und MINUTE aus FireBird Lib

• Unterschiede bei Verzeichnisnamen/u]
  in TF5k:
  DataFiles
  MP3
  ProgramFiles
  ProgramFiles/Auto Start
  
  im TMS:
  DataFiles
  MediaFiles
  MP3Files
  PhotoFiles
  ProgramFiles
  ProgramFiles/AutoStart

• Unterschiede in Konstanten/Typen der TMS API v0.1 gegenüber TF5k (1):
  in TF5k laut HDD.H noch 4 Attribut-Werte (ATTR_NORMAL, ATTR_TS, ATTR_PROGRAM, ATTR_FOLDER)
  im TMS laut hdd.h nur noch 2 Attribut-Werte (ATTR_NORMAL und ATTR_FOLDER)

• Unterschiede in Konstanten/Typen der TMS API v0.1 gegenüber TF5k (2):
  in TF5k laut HDD.H "TS_FILE_NAME_SIZE 100"
  im TMS laut hdd.h "MAX_FILE_NAME_SIZE 127"

• Unterschiede in Konstanten/Typen der TMS API v0.1 gegenüber TF5k (3):
  in TF5k laut HDD.H "SIZE_FileBlock 512"
  im TMS laut hdd.h => gibts nicht mehr

• Unterschiede in Konstanten/Typen der TMS API v0.1 gegenüber TF5k (4):
  in TF5k laut HDD.H
  nur TYPE_File mit diversen Variablen, u.a. auch clusterbezogene
  
  im TMS laut hdd.h:
  
  typedef struct
  {
  dword info;
  dword time; // mjd << 16 | h << 8 | m
  long64 size;
  char name[ MAX_FILE_NAME_SIZE + 1];
  void* handle;
  } TYPE_File;
  
  typedef struct
  {
  dword attr;
  dword info;
  dword time; //mjd << 16 | h<<8 | m
  long64 size;
  char name[ MAX_FILE_NAME_SIZE + 1 ];
  } TYPE_FolderEntry;

• Unterschiede in Konstanten/Typen der TMS API v0.1 gegenüber TF5k (5):
  in TF5k laut TAP.H:
  typedef struct
  {
  void *eAddr; // even address (the address of top field)
  void *oAddr; // odd address (the address of bottom field)
  word width;
  word height;
  word bytePerPixel; // 256 color = 1, ARGB1555 = 2, ARGB8888 = 4
  word dataFormat;
  word reserved[4];
  } TYPE_OsdBaseInfo;
  
  im TMS laut tap.h:
  typedef struct
  {
  void *frameBuffer; //the address of the frame
  word width;
  word height;
  word bytePerPixel; // 256 color = 1, ARGB1555 = 2, ARGB8888 = 4
  word dataFormat; //OSD8888, OSD1555, OSD256
  byte enabled;
  byte visible;
  int zorder;
  } TYPE_OsdBaseInfo;
  (betrifft Funktion "int TAP_Osd_GetBaseInfo( TYPE_OsdBaseInfo *info )")

So, das müsste erstmal fast alles sein, was mir bisher über den Weg gelaufen ist. Vielleicht fällt mir ein andermal noch mehr ein.

Hoffentlich hat mich meine Erinnerung nicht irgendwo im Stich gelassen.

Außerdem bitte auch meine zwei ersten Bemerkungen aus Post 3 beachten.

Mit diesem Know-How kann jetzt bestimmt bald jeder TAPs portieren :
...

Änderungen:
09.10.09: geänderte SAT-Taste, TAP_DiffTick und <string.h> hinzugefügt
10.10.09: TAP_MemAlloc und strcpy bei Abstürzen, AutoStart bei Verzeichnisnamen

[FireBird]

Wie lange bist Du denn dabei gesessen?

wobei scheinbar 0 für transparent steht, also RGB(0, 0, 0) = COLOR_None und nicht COLOR_Black, ich vermute mal, COLOR_Black = RGB(1, 1, 1) oder doch 0 aber mit korrekter Belegung des Alpha-Wertes

Ich halte das für einen Firmware-Bug.

Code: Alles auswählen

RGB(0, 0, 0) = RGB8888(0, 0, 0) = ARGB(TAP_ALPHA, 0, 0, 0)

sollte eigentlich schwarz sein, und nicht transparent. Sobald eine der 3 Grundfarben >=8 ist, werden die Pixel nicht mehr transparent gemalt. Ich sehe gerade, dass die Schurken in der tap.h folgenden Eintrag gemacht haben:

Code: Alles auswählen

#define COLOR_Black         RGB8888(16, 16, 16)

Das ist ja fast schon Weiß. Ich habe es trotzdem vor einiger Zeit als Bug gemeldet.

[xyzzyx]

Here is the translation for our english speaking friends:

Even if it maybe have no use very long... hopefully there will be a better TMS API soon... But maybe Gerti could give it as input to Korea.

Documentation-bugs:

• Errors in TMS API Documentation v0.1 (1):
  Timer-functions are still supported by the TMS API (see TimerList.c example), although they are missing in the TMS API documentation

• Errors in TMS API Documentation v0.1 (2):
  Function "int TAP_Channel_ExchangePip(void);" is defined in tap.h, but it is missing in the documentation
  with PIP activated it swaps the main- and PiP-image (like the SAT-key)
  it is a new function on the TMS models compared to TF5k

• Errors in TMS API Documentation v0.1 (3):
  Function "dword TAP_Hdd_FindFirst( TYPE_FolderEntry* file, const char* extension);" is defined in tap.h, but is documented incorrectly as "dword TAP_Hdd_FindFirst( TYPE_File *file )"
  it can be used to find all files (use NULL for the extension parameter), or just files for one or more particular extensions
  Example:
  "TYPE_FolderEntry file;"
  "totalEntry = TAP_Hdd_FindFirst( &file, "jpg|jpeg");" or
  "totalEntry = TAP_Hdd_FindFirst( &file, NULL);"
  there is a new variable "extension" on the TMS models compared to TF5k and file is on TMS now of TYPE_FolderEntry (see hdd.h), on TF5k it was of TYPE_File

• Errors in TMS API Documentation v0.1 (4):
  Function "dword TAP_Hdd_FindNext( TYPE_FolderEntry* file);" is defined in tap.h, but is documented incorrectly as "dword TAP_Hdd_FindNext( TYPE_File *file )"
  file is on TMS now of TYPE_FolderEntry (see hdd.h), on TF5k it was of TYPE_File

• Errors in TMS API Documentation v0.1 (5):
  Function "int TAP_Osd_Zoom( int xzoom, int yzoom );" is defined in tap.h, but is missing in the documentation
  FireBird has found out that there is no sourcecode in it
  the function was probably available on TF5k (in TAP.H and documentation), but on TMS it does not do anything

• Errors in TMS API Documentation v0.1 (6):
  Function "TYPE_Window TAP_Win_Create(word rgn, dword x, dword y, dword w, dword h, dword maxItem, byte save, byte bScr );" is defined in tap.h, but is incorrectly documented as "TYPE_Window TAP_Win_Create( TYPE_Window win, word rgn, dword x, dword y, dword w, dword h, dword maxItem, byte bScr )"
  the following parameters would be correct: "region, pos-x, pos-y, width, height, max. number of items, save, scrollbar", save is meant to save the background image before the window is painted
  compared to TF5k it is new that TYPE_Window is now the return value on TMS and not the first parameter any more
  with maxItem there is a new parameter for specifying the maximum number of items

• Errors in TMS API Documentation v0.1 (7):
  Function "dword TAP_DiffTick(dword oldTick, dword newTick);" is defined in tap.h, but is missing in the documentation
  it is a new function on the TMS models compared to TF5k

• Errors in TMS API Documentation v0.1 (8):
  Function "(int) TAP_Osd_SetTransparency(word rgn, char rt);" is defined incorrectly in tap.h and is missing in the documentation
  compared to the TF5k the first parameter on the TMS models is not the region any more but the character plane
  the possible constants are defined in the tap.h:
  #define BASE_PLANE 0 // osd base, ttx
  #define SUBT_PLANE 1 // subtitle
  #define TAP_PLANE 2 // tap
  mainly you will use TAP_PLANE on TMS as first parameter
  on the TF5k the values for rt are between 0 and 63
  on the TMS the values for rt are between 0 and 255 and you have to subtract the value of SYSVAR_OsdAlpha

• Errors in TMS API Documentation v0.1 (9):
  Function "(int) TAP_PlayPCM( void *pcmdata, int size, int freq, void (*Callback)(void) );" is defined and documented but does not play any sound with the current released firmware (at least on TMS model SRP-2100).

Now some good knowledge for the TAP-porters or TMS TAP programming newcomers:
Worth knowing:

• Key changes/u]
  compared to the TF5k you should change the following keys for the TMS models
• directional pad
  from RKEY_VolDown to RKEY_Left
  from RKEY_VolUp to RKEY_Right
  from RKEY_ChUp to RKEY_Up
  from RKEY_ChDown to RKEY_Down
• define the white/option key that is missing in key.h in your own source codeif necessary (determined by KeyRecord example)
  #define RKEY_White 0x10049
• the red F1 key is not RKEY_F1 but RKEY_NewF1 (but was apparently on TF5k in the same way too)
  #define RKEY_Red RKEY_NewF1
• on the TMS models the SAT-key is not RKEY_TvSat (0x10022) but RKEY_Sat (0x10040), nevertheless RKEY_TvSat (0x10022) still exists on the TMS models and represents the "M"-key (scart-source)

• Key Events/u]
  compared to the TF5k you get the following new key events on the TMS models
• start of the repeat (key pressed and held)
  - signalled by 2^24 (0x1000000), means that the 7th bit (from left) of the 32 bit dword is set to 1
• end of the repeat (key released)
  - signalled by 2^25 (0x2000000), means that the 6th bit (from left) of the 32 bit dword is set to 1
• example (pressing and holding the STOP-key):
  - key 0x0001003C (0x1003C)
  - key 0x0101003C (0x101003C)
  - key 0x0001003C (0x1003C)
  - key 0x0001003C (0x1003C)
  - as often as holded...
  - key 0x0001003C (0x1003C)
  - key 0x0001003C (0x1003C)
  - key 0x0201003C (0x201003C)
• if you just press the key short you will get this:
  - key 0x0001003C (0x1003C)
  - key 0x0201003C (0x201003C)

• OSD-synchronisation (very important because it is the most common reason for display problems on the TMS models):
  on the TF5k models building up the OSD was apparantly done internally
  on the TMS models building up the OSD has to be done manually done after the usage of OSD or window functions by calling "TAP_Osd_Sync();" (void TAP_Osd_Sync(void) )!
  if you use TAP_Osd_Sync the function TAP_Win_Draw does not seem to be really necessary

• Color values (auch siehe macfan und FireBird):
  on the TF5k models the color fields are of type word and the single RGB values are between 0 and 31
  on the TMS models the color fields are of type dword and the single RGB values are between 0 and 255
  xyzzyx' impression:
  0 seems to stand for transparency, that means RGB(0, 0, 0) is COLOR_None and not COLOR_Black, as FireBird found out COLOR_Black is defined as RGB(16,16,16) in tap.h and he thinks it is a firmware bug and reported it to Topfield a while ago
  FireBird contributes:
  everybody who uses the ARGB-macro and feed it with values between 0 and 31 will get very dark colors, because each primary color on the TMS has 8 bits and therefore has 255 as highest value
  the quickest will be a definition of an own ARGB-macro that multiplies the submitted values invisibly by 8.22 (~ 255/31).
  in this connection here is the additional information that the alpha flag on the TMS models is not 1 any more but has to be 255 for not painting transparently
  the best is to use the predefined tap.h constant TAP_ALPHA

• Data types/u]
  compared to the TF5k the TMS compiler pays more attention to signed and unsigned data types in comparision operations
  solutions: use the correct data types for the variables (e.g. int instead of dword) or try type conversion in the comparision (e.g. "if ( (int) delta > 0)", just from my memory, not tested again)

• <string.h>/u]
  for the TMS compiler you must put 'Include <string.h>' directly before 'Include "tap.h" ' to be able to use string functions like strlen or strcpy
  on the TF5k models the string library seems to be included automatically

• Unused variables/u]
  for the TMS compiler you can avoid compiler warnings about unused variables by adding the TMS internal macro "UNUSED(dwParam2);"
  as an alternative you could remove the unused variables

• Warning not to use the variable "wait"/u]
  probably there is naming conflict on the TMS models regarding the variable "wait"
  it seems to be used internally on the TMS and globally
  this can lead to wrong values
  wait seems to have always a fixed value, with a test output formatted to %08X it was "3C1C0001"
  assignments of GetTick to wait can lead to reboots/crashes

• Frequent reasons for TMS reboots/crashes with TAP API v0.1:
• access to an array without previous testing whether you use an allowed index value
• under several circumstances with character strings with fixed length or pointers to strings without previous initialization or memory allocation (sometimes you have to use strcpy instead of TAP_SPrint), do not forget to free the memory if you do not need it any more
  Example (without TAP_MemAlloc it may lead to a reboot/crash):
  Items[itemNo] = TAP_MemAlloc(strlen(str) + 1);
  if(Items[itemNo]) strcpy(Items[itemNo], str);
• with something like that:
  TAP_Win_SetDefaultColor (&g_wndExit);
  TAP_Win_Create (&g_wndExit, g_rgn, 225, 200, 255, 44, FALSE, FALSE);
  TAP_Win_SetTitle (&g_wndExit, PROGRAM_NAME, 0, FNT_Size_1622);
  TAP_Win_AddItem (&g_wndExit, "Exit AutoZapper");
  TAP_Win_AddItem (&g_wndExit, "Cancel");
  TAP_Win_SetSelection (&g_wndExit, 1);
• changed to (&-character remove, meant "address of"):
  TAP_Win_SetDefaultColor (g_wndExit);
  g_wndExit = TAP_Win_Create (g_rgn, 225, 200, 255, 44, 2, FALSE, FALSE);
  TAP_Win_SetTitle (g_wndExit, PROGRAM_NAME, 0, FNT_Size_1622);
  TAP_Win_AddItem (g_wndExit, "Exit AutoZapper");
  TAP_Win_AddItem (g_wndExit, "Cancel");
  TAP_Win_SetSelection (g_wndExit, 1);

• Frequent reasons for wrong values (sometimes leads to reboots/crashes too) with TMS TAP API v0.1:
• variable "wait" (see above)
• demux-filter still has bugs or is insufficient for PES-streams
• with something like this (converting pointers for access to a part of the field or data type enlargement):
  #define NOW *(dword*)&myDate.mjd
  ...
  TAP_ExtractMjd( *(word*)&rr.recStart, &myDate.year, &myDate.month, &myDate.day, &myDate.weekDay );
  ...
  #define BYTE(x,y) ((byte*)&rr.x)[y] //for dword fields with format mjd (word), hour (byte), minute (byte)
• changed to:
  #define NOW DATE(myDate.mjd, myDate.hour, myDate.min) //DATE from FireBird Lib
  ...
  TAP_ExtractMjd( MJD(rr.recStart), &myDate.year, &myDate.month, &myDate.day, &myDate.weekDay ); //MJD from FireBird Lib
  ...
  //BYTE-Macro avoided by using HOUR and MINUTE macros instead from FireBird Lib

• Differences in directory names/u]
  on TF5k:
  DataFiles
  MP3
  ProgramFiles
  ProgramFiles/Auto Start
  
  on TMS:
  DataFiles
  MediaFiles
  MP3Files
  PhotoFiles
  ProgramFiles
  ProgramFiles/AutoStart

• Differences in constants/types of TMS API v0.1 compared to TF5k (1):
  on TF5k there were still four attribute values according to hdd.h (ATTR_NORMAL, ATTR_TS, ATTR_PROGRAM, ATTR_FOLDER)
  on TMS according to hdd.h there are only two attribute values (ATTR_NORMAL and ATTR_FOLDER)

• Differences in constants/types of TMS API v0.1 compared to TF5k (2):
  on TF5k according to HDD.H "TS_FILE_NAME_SIZE 100"
  on TMS according to hdd.h "MAX_FILE_NAME_SIZE 127"

• Differences in constants/types of TMS API v0.1 compared to TF5k (3):
  on TF5k according to HDD.H "SIZE_FileBlock 512"
  on TMS according to hdd.h => does not exist any more

• Differences in constants/types of TMS API v0.1 compared to TF5k (4):
  on TF5k according to HDD.H
  only TYPE_File with several variables, regarding clusters too
  
  on TMS according to hdd.h:
  
  typedef struct
  {
  dword info;
  dword time; // mjd << 16 | h << 8 | m
  long64 size;
  char name[ MAX_FILE_NAME_SIZE + 1];
  void* handle;
  } TYPE_File;
  
  typedef struct
  {
  dword attr;
  dword info;
  dword time; //mjd << 16 | h<<8 | m
  long64 size;
  char name[ MAX_FILE_NAME_SIZE + 1 ];
  } TYPE_FolderEntry;

• Differences in constants/types of TMS API v0.1 compared to TF5k (5):
  on TF5k according to TAP.H:
  typedef struct
  {
  void *eAddr; // even address (the address of top field)
  void *oAddr; // odd address (the address of bottom field)
  word width;
  word height;
  word bytePerPixel; // 256 color = 1, ARGB1555 = 2, ARGB8888 = 4
  word dataFormat;
  word reserved[4];
  } TYPE_OsdBaseInfo;
  
  on TMS according to tap.h:
  typedef struct
  {
  void *frameBuffer; //the address of the frame
  word width;
  word height;
  word bytePerPixel; // 256 color = 1, ARGB1555 = 2, ARGB8888 = 4
  word dataFormat; //OSD8888, OSD1555, OSD256
  byte enabled;
  byte visible;
  int zorder;
  } TYPE_OsdBaseInfo;
  (regards to function "int TAP_Osd_GetBaseInfo( TYPE_OsdBaseInfo *info )")

• Differences in constants/types of TMS API v0.1 compared to TF5k (6):
  contributed by FireBird in the Filer thread:
  on TF5k the blocksize is 96256 bytes per block
  on TMS the blocksize is 9024 bytes per block

• Differences in constants/types of TMS API v0.1 compared to TF5k (7):
  Not directly a constant or type of the API but the unique ID of the TAP:
  #define ID_USERTAP 0x80000123 // user defined id , id = 0x0000123
  TAP_ID( ID_USERTAP );
  In the documentation it says that "it is no longer used in TMS".
  That means that it is possible to start TAPs with the same ID twice or more often on the TMS. It is not avoided!
  If the user starts a TAP twice it could lead to errors regarding the keys or the functionality of the TAP!

So, that should be everything that I recognized till now.
Maybe something more will come to my mind later.

With this knowledge nearly everybody could convert TAPs from TF5k to TMS models :
...

Changes:
09-10-13 information about variable rt in TAP_Osd_SetTransparency added
09-10-20 information about new TMS key events added (contributed by John De Angelis)
09-10-20 information about TAP_PlayPCM and warning about TAP_ID added

[xyzzyx]

John De Angelis bestätigte meine schon kurz bei der Portierung von key_display erkannte Situation mit den neuen TMS Key Events:

• Key Events/u]
  gegenüber dem TF5k bekommt man auf dem TMS die folgenden neuen Key Events
• Start einer Wiederholung (Taste gedrückt und gehalten)
  - erkennbar an 2^24 (0x1000000), d.h. das 7. Bit (von links) des 32 Bit langen dword ist auf 1 gesetzt
• Ende einer Wiederholung (Taste losgelassen)
  - erkennbar an 2^25 (0x2000000), d.h. das 6. Bit (von links) des 32 Bit langen dword ist auf 1 gesetzt
• Beispiel (drücken und festhalten der STOP-Taste):
  - key 0x0001003C (0x1003C)
  - key 0x0101003C (0x101003C)
  - key 0x0001003C (0x1003C)
  - key 0x0001003C (0x1003C)
  - so oft wie sie gehalten wird...
  - key 0x0001003C (0x1003C)
  - key 0x0001003C (0x1003C)
  - key 0x0201003C (0x201003C)
• wenn man die Taste nur kurz drückt, bekommt man folgendes:
  - key 0x0001003C (0x1003C)
  - key 0x0201003C (0x201003C)

[xyzzyx]

• Unterschiede in Konstanten/Typen der TMS API v0.1 gegenüber TF5k (7):
  Nicht direkt eine Konstante der ein Typ der API aber die eindeutige ID des TAPs:
  #define ID_USERTAP 0x80000123 // user defined id , id = 0x0000123
  TAP_ID( ID_USERTAP );
  In der Dokumentation steht "it is no longer used in TMS" (es wird nicht mehr im TMS benutzt).
  Somit ist es möglich, TAPs mit derselben ID doppelt oder mehrfach zu starten. Es wird nicht verhindert!
  Wenn der Benutzer ein TAP doppelt startet, dann führt das zu Fehlern bezüglich der Tasten oder der Funktionalität des TAPs!

• Stichwort Dokufehler in TMS API Doku v0.1 (8):
  Funktion "(int) TAP_PlayPCM( void *pcmdata, int size, int freq, void (*Callback)(void) );" ist definiert und dokumentiert aber spielt mit der momentan freigegebenen öffentlichen Firmware keinen Ton ab (zumindest beim TMS Modell SRP-2100). Also eigentlich ein Firmware-Bug (kein Doku-Bug).

[FireBird]

Beim TMS wurde TYPE_PlayMode durch weitere Konstanten erweitert, diese aber nicht in der tap.h eingetragen.

PlayMode 6 = ???
PlayMode 7 = MediaFiles AVI
PlayMode 8 = MediaFiles MPG, MKV

Wer findet heraus, wofür die 6 verwendet wird?

[FireBird]

Ist keine Änderung, sondern eine Neuerung, aber leider eine halbherzig durchgeführte. Die Firmware exportiert eine neue API-Funktion

Code: Alles auswählen

TAP_GetActiveTuner(unsigned char MainSub);

Man hat nur vergessen, sie auch in die tap.h einzutragen. Somit muß man die folgende Zeile in eine eigene .h oder .c hinzufügen:

Code: Alles auswählen

extern unsigned char (*TAP_GetActiveTuner)(unsigned char);

[FireBird]

Jetzt wieder ein Unterschied:

Wollte man früher wissen, ob Timeshift gerade aktiv ist, mußte man die beiden Slots 0 und 1 abfragen und auf recType == RECTYPE_Timeshift testen. Beim TMS ist der Slot 2 für TS vorgesehen.

If one needs to know if time shift is active on a TF5k, it was necessary to check slots 0 and 1 and test for recType == RECTYPE_Timeshift. On the TMS, slot 2 is reserved for the TS details.

Code: Alles auswählen

TYPE_RecInfo          RecInfo;

TAP_Hdd_GetRecInfo(2, &RecInfo);
if(RecInfo.recType == RECTYPE_Timeshift)
{
  …
}

[xyzzyx]

Nikolaus-Update...

Beim TMS wurde TYPE_PlayMode durch weitere Konstanten erweitert, diese aber nicht in der tap.h eingetragen.

PlayMode 6 = ???
PlayMode 7 = MediaFiles AVI
PlayMode 8 = MediaFiles MPG, MKV

Wer findet heraus, wofür die 6 verwendet wird?

Ich würde eher sagen, dass es mit der FW 1.06.01 so lauten müsste (anbei ein Test-TAP):

Code: Alles auswählen

#define PLAYMODE_AVI		6
#define PLAYMODE_TS_MKV_MP4_MPG 7

PlayMode 6 = MediaFiles AVI
PlayMode 7 = MediaFiles TS, MKV, MP4(, MPG)

Erkannte Probleme:
- Im Media Player werden keine .mpeg Erweiterungen angezeigt.
- Nur .mpg wird angezeigt, führte aber bei mir zu keinerlei Abspielvorgang (nur kurz gestartet und ohne Bild wieder sofort beendet). Teilweise führte .mpg sogar schon in der TMS-Fileliste des Media Players zum Absturz (in meinem Fall bei einem MPEG-1 Testvideo).

Kommen deine Unterschiede vielleicht durch eine Beta-Firmware oder hast du dich einfach vertan?

... und wech ...

[FireBird]

Kommen deine Unterschiede vielleicht durch eine Beta-Firmware

Scheint wirklich so zu sein.

[FireBird]

TAP_GetTick() liefert zwar weiterhin einen Tick-Count im 100ms-Rhythmus, beginnt aber, im Gegensatz zum 5000er, nicht bei 0 und läßt sich somit nicht dazu verwenden, die Zeit seit dem Topf-Start zu berechnen. Für diesen Zweck kann die folgende Routine verwendet werden. Aus Kompatibilitätsgründen arbeitet auch sie mit 100ms-Ticks.

Code: Alles auswählen

#include                <stdio.h>
#include                <locale.h>

dword GetUptime(void)
{
  FILE                 *fp;
  double                upsecs;
  dword                 uptime = 0;

  fp = fopen("/proc/uptime", "r");
  if(fp != NULL)
  {
    char                buf[BUFSIZ];
    int                 res;
    char               *b;

    b = fgets(buf, BUFSIZ, fp);
    if(b == buf)
    {
      /* The following sscanf must use the C locale.  */
      setlocale(LC_NUMERIC, "C");
      res = sscanf(buf, "%lf", &upsecs);
      setlocale(LC_NUMERIC, "");
      if(res == 1) uptime = (dword)(upsecs * 100);
    }
    fclose (fp);
  }

  return uptime;
}

[Erdnussnase]

• Warnung vor der Verwendung der Variable "wait":
  vermutlich gibt es einen Namenskonflikt beim TMS bzgl. Variable "wait"
  wird scheinbar intern vom TMS global verwendet
  kann zu falschen Werten führen
  wait steht immer auf einem festen Wert, bei Test-Ausgabe mit %08X war es "3C1C0001"
  Zuweisung von GetTick zu wait kann zu Absturz führen
  

Ich habe etwas ähnliches. Die Verwendung des Namens
Keyboard_Init(...)
für eine Routine wird vom Compiler/Linker nicht angemeckert. Bei der Ausführung wird jedoch nicht die eigene Keyboard_Init angesprungen, sondern man landet in den Tiefen des TMS aus denen man (meist) dummerweise wieder herauskommt als sei nichts gewesen.

Ich habe mir daher eine blacklist.h gebaut die derzeit folgendermaßen aussieht.

Code: Alles auswählen

#ifndef _BLACKLIST_H_
#define _BLACKLIST_H_

#define wait                    <Do not use this name>
#define Keyboard_Init           <Do not use this name>

#endif

[FireBird]

Nachdem es immer wieder Verwirrung bezüglich des Alpha-Kanals bei den OSD-Funktionen gibt, habe ich mir die einzelnen Befehle angesehen und ein paar Beispiele durch gespielt. Dabei haben sich 3 Gruppen herauskristallisiert:

1.) Funktionen, die Pixel direkt in den Speicher schreiben.

TAP_Osd_DrawRectangle(), TAP_Osd_FillBox(), TAP_Osd_PutPixel(), TAP_Osd_Draw3dBox(), TAP_Osd_Draw3dBoxFill() und TAP_Osd_RestoreBox()(?*)

Es erfolgt keine Manipulation, die Farben werden direkt in den Framebuffer geschrieben. Der Alpha-Kanal gibt an, wie stark das Videobild durchscheint (0=voll transparent, 255=kein Video zu sehen). Es gibt einen Spezialfall: ARGB(a,0,0,0) wird, unabhängig von dem Alpha-Wert a, immer transparent angezeigt. Dies ist dann ein Problem, wenn dunkle Bilder in das OSD kopiert werden, da dann das Videobild durch einzelne Punkte durchscheint.

2.) Stringfunktionen

TAP_Osd_PutS(), TAP_Osd_PutString(), TAP_Osd_PutStringAf(), TAP_Osd_DrawString()(?)

Sie unterscheiden sich in einem Punkt von der Gruppe 1: Pixel mit der Farbe(0,0,0,0) werden nicht gezeichnet. Das bedeutet, daß ein darunter liegendes OSD-Pixel „überlebt“.

3.) Funktionen mit dem Parameter „sprite“

TAP_Osd_Copy(), TAP_Osd_PutGd(), TAP_Osd_PutBox()(?), TAP_Osd_DrawPixmap()(?)

Diese Funktionen kopieren Bilddaten aus einem Speicherbereich/OSD in ein OSD. Der Parameter sprite bestimmt, ob ein Pixel mit der Farbe (0,0,0,0) kopiert werden soll (sprite=false, Verhalten wie Gruppe 1), oder nicht (sprite=true, Verhalten wie bei Gruppe 2).


Meines Wissens gibt es keine API-Funktion, die eine Transparenz zwischen 2 OSD-Bildpunkten berechnet – es gibt nur Hintergrund ((0,0,0,0) bei sprite=true) oder Vordergrund. Falls man dies benötigt, muss man die Berechnung selbst programmieren (wie z.B. das Antialiasing im FontManager).


Um zu verhindern, daß Bilder oder Icons durchlöchert werden, gibt es zwei Möglichkeiten: man lädt das Bild in eine temporäre Mem-Region und kopiert sie dann in die Zielregion mit TAP_Osd_Copy(sprite=true). In diesem Fall bleibt das Hintergrund-OSD erhalten. Diese Methode ist speicherintensiver, da ein Bild kurzfristig zwei Mal im Speicher steht, und eignet sich eher für Icons. Bei Bildern kann man den Speicher direkt nach (a,0,0,0) durchsuchen und diese Pixel auf (a,4,4,4) setzen. Dadurch werden die „Videolöcher“ gestopft.



* Alle Funktionen mit einem ? habe ich nicht explizit getestet, gehe aber auf Grund der Funktionsparameter davon aus, daß sie zu der Gruppe gehören.

[Erdnussnase]

[quote="FireBird"]Nachdem es immer wieder Verwirrung bezüglich des Alpha-Kanals bei den OSD-Funktionen gibt, habe ich mir die einzelnen Befehle angesehen und ein paar Beispiele durch gespielt.[/quote]
Das ist so wie es auch bei den äteren Töpfen funktioniert.
Was aber noch erwähnt werden sollte ist, das alle Transparenzen sich auf die im TMS Menü eingestellte Transparenz beziehen. Soll heißen, man gibt z.B. in seinem OSD keine Transparenz an. Dann ist mit "keiner" die gemeint die im TMS Menü x% ist.
Ob das bei den älteren auch so war weiß ich nicht.

[FireBird]

[quote="Erdnussnase"]Ob das bei den älteren auch so war weiß ich nicht.[/quote]
Yep, die Basistransparenz wurde immer schon von der Menüeinstellung vorgegeben.