SLB 'devkit' ?

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

SLB 'devkit' ?

Postby JeanMars » Mon Sep 10, 2018 6:44 am

Hi,

I need to use SLB shared libraries for Mint/Magic but slb.h is missing on my Aranym (comes from EasyMint) install.
So I am wondering how to get the devkit (I'm using PureC) and have SLB available on my install.
Googled that a bit but did not find any valuable information, can someone explain this to me or point me to the web resource I may have missed?

Thanks,
Jean

mikro
Hardware Guru
Hardware Guru
Posts: 2016
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: SLB 'devkit' ?

Postby mikro » Mon Sep 10, 2018 8:50 am

Look here: http://toshyp.atari.org/en/00b017.html

There you can find not only some information but also the mentioned slb.h

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Mon Sep 10, 2018 8:50 pm

Hi,

looks like there is everything I need to understand, thanks!

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 750
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Tue Sep 11, 2018 8:58 am

JeanMars wrote:slb.h is missing on my Aranym (comes from EasyMint) install.


Actually its from mintlib, and rather short. For Pure-C, you can use this one

Code: Select all

/* 
 * Copyright (C) 2000 Konrad Kokoszkiewicz <draco@atari.org.pl>
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Library General Public
 * License as published by the Free Software Foundation; either
 * version 2 of the License, or (at your option) any later version.
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Library General Public License for more details.
 *
 * You should have received a copy of the GNU Library General Public
 * License along with this library; if not, write to the Free
 * Software Foundation, Inc., 59 Temple Place - Suite 330, Boston,
 * MA 02111-1307, USA
 *
 */

# ifndef _MINT_SLB_H
# define _MINT_SLB_H 1

/* MagiC 5.20 Share Library Support */

typedef struct _slb_handle { int dummy; } *SLB_HANDLE, *SHARED_LIB;
typedef long  cdecl (*SLB_EXEC)(SLB_HANDLE slb, long fn, short nwords, ...);

typedef struct {
   SLB_HANDLE   handle;
   SLB_EXEC   exec;
} SLB;


long _slbopen (const char *fname, const char *path, long ver, void *hnd, void *exec);


# endif /* mint/slb.h */




The only difference to the original is the "cdecl" keyword. If you get compile errors there, you have to turn off -A (ansi keywords only), but take care that Pure-C then also does not define __STDC__. The _slbopen() function is just a wrapper to the gemdos function, which you may also need:

Code: Select all

            GLOBL   Slbopen      /* Magic 5.20 */
            GLOBL   Slbclose   /* Magic 5.20 */
            
            MODULE   Slbopen
            pea      (a2)
            move.l   12(a7),-(a7)
            move.l   12(a7),-(a7)
            move.l   d0,-(a7)
            move.l   a1,-(a7)
            move.l   a0,-(a7)
            move.w   #$16,-(a7)
            trap #1
            lea      22(a7),a7
            move.l   (a7)+,a2
            rts
            ENDMOD
                        
            MODULE   Slbclose
            pea      (a2)
            move.l   a0,-(a7)
            move.w   #$17,-(a7)
            trap #1
            addq.l   #6,a7
            move.l   (a7)+,a2
            rts
            ENDMOD


and also the declaration somewhere:

Code: Select all

/* MagiC 5.20 Share Library Support */
long Slbopen(const char *name, const char *path, long min_ver, SLB_HANDLE *slb, SLB_EXEC *slbexec); /* GEMDOS 0x16 */
long Slbclose(SLB_HANDLE slb);            /* GEMDOS 0x17 */


how to get the devkit

I'm not aware of any "devkit", there has only been some example code for MagiC.

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Mon Sep 02, 2019 10:38 am

Hi,

I'm facing an issue when using PureC; slbopen looks OK but any attempt to run a function leads to err -32 (invalid function number).
I guess this has to do with the function call which is cdecl but slb.h mentions:
/*
Unfortunately this does not work in Pure-C, because Pure-C has an
error (!!!) here: cdecl is ignored if the function has a variable
number of parameters.

typedef long (cdecl *SLB_EXEC)(SHARED_LIB *sl, long fn, short nargs, ... );
*/
typedef long (*SLB_EXEC)(void , ... ) ;

So when trying to make a call:
Slbopen( name, path, 0L, &img_module->hLib, &img_module->SlbExec ) ;
And later on:
img_module->SlbExec( ImgModule->hLib, 8, SLB_NARGS(1), which )
this call fails with -32 which makes sense as SlbExec is cdecl but not declared as cdecl because PureC has a bug there. So func num (8 here) is not passed as expected.
How to deal with that?

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 750
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Mon Sep 02, 2019 2:59 pm

I don't know where you found the comment about cdecl, but it is wrong. just declare it as

Code: Select all

typedef long  cdecl (*SLB_EXEC)(SLB_HANDLE slb, long fn, short nwords, ...);


Note that the cdecl keyword here is outside the parentheses.

*Not* using cdecl cannot work, because Pure-C then passes the first 3 parameters in registers. And the exec function is supplied by MiNT/MagiC, so it cannot be changed.

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Mon Sep 02, 2019 3:52 pm

Hi Thorsten,

I found the comment on the 'official' Magic library page same as in toshyp but moved to github: https://freemint.github.io/tos.hyp/en/m ... relib.html (also at the very end in 11.23.10 SLB.H, cdecl is missing)

I'll try adding the cdecl keyword as it has to be there anyway.
Would be good to fix this error on the webpage as it confused me a lot :-)
Cheers,
Jean

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 750
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Mon Sep 02, 2019 4:55 pm

That must have been copied from a very old version. Without a correct declaration, the examples supplied with MagiC would not work. See also https://gitlab.com/AndreasK/Atari-Mac-M ... /SLB.H#L21

Fixed now also in tos.hyp

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Thu Sep 05, 2019 8:22 pm

Hi,

I'm still fighting against SLB zView plugins being called...
On Aranym, function ordinal 8 (SLB_get_option) is OK and returns correctly the list of file extensions but it then crashes on ordinal 1 (SLB reader_init).
On MagicPC 6, it crashes at function ordinal 8.
I made a screenshot of a debug session under MagicPC, if that can help.
My understanding is that the handle to SLB returned by Slbopen returns a pointer to SLB_HEADER:
#define SLB_MAGIC 0x70004AFCL
typedef struct
{
long magic ;
const char *name ;
long version ;
long flags ;
void cdecl (*slb_init) (void) ;
void cdecl (*slb_exit) (void) ;
void cdecl (*slb_open) (void*) ;
void cdecl (*slb_close) (void*) ;
const char *const *procnames ;
long next ;
long reserved[7] ;
long num_funcs ;
/* long funcs_table[]; */
} SLB_HEADER, *PSLB_HEADER ;

In this case, for some reason this pointer is wrong on Aranym/Magic as magic filed is incorrect:
SLB Header dump 238a4:
magic =$29260 (INcorrect)
name =p
version =$10167
flags =$3BC80000
num_funcs =0

Some relevant pieces of code:
tools/imgmodule.c:
ret = Slbopen( name, last_slash ? path:NULL, 0L, &img_module->hLib, &img_module->SlbExec ) ;
hLib and SlbExec are declared as:
void* hLib ; /* Handle of the lib, could be LDG or SLB */
SLB_EXEC SlbExec ; /* Functions pointer (SLB only) */

tools/iizview.c:
status = ImgModule->SlbExec( ImgModule->hLib, 8L, SLB_NARGS(1), (long)which ) ; /* All parameters must be 4 byte long */
...
status = img_module->SlbExec( img_module->hLib, 1L, SLB_NARGS(2), name, info ) ;

tools/slb.h:
typedef void* SHARED_LIB ;
typedef long cdecl (*SLB_EXEC)(SHARED_LIB sl, long fn, short nargs, ... ) ;
extern long Slbopen(char* name, char* path, long min_ver, SHARED_LIB* sl, SLB_EXEC* fn) ;

I should have made a stupid mistake but I can't find it. If somebody can help, I appreciate :-)
Full source code is available at http://vision.atari.org/download/temp/srcvis.zip
Thanks,
Jean
You do not have the required permissions to view the files attached to this post.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 750
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Thu Sep 05, 2019 9:50 pm

JeanMars wrote:My understanding is that the handle to SLB returned by Slbopen returns a pointer to SLB_HEADER:


That is the case on MiNT IIRC, but need not be. I think in MagiC it points to some internal structure. Just treat it as an opaque type that you pass along when calling functions.

status = ImgModule->SlbExec( ImgModule->hLib, 8L, SLB_NARGS(1), (long)which ) ; /* All parameters must be 4 byte long */
typedef long cdecl (*SLB_EXEC)(SHARED_LIB sl, long fn, short nargs, ... ) ;


How is SLB_NARGS defined? That's a macro i once invented to encode the number of arguments. The problem here is the third parameter to the exec function, which is declared as short. With GNU-C, it is actually impossible to call the function directly like intended, and push only a short on the stack, it will always be promoted to 32-bit ints. In the implementation of zlib etc. i therefore encode it as long in a way that the upper 16 bits of this long reflect the number of words+1 (since it pushes 1 word more), and the lower 16 bits contains the number of words.
With Pure-C, when calling the exec function directly, you can achieve the same effect by defining

Code: Select all

#define SLB_NARGS(x) 0, x


See also https://github.com/th-otto/zview/blob/9 ... .c#L22-L28

Note that this is not the same as passing a long like with Gnu-C, since the third parameter is typedef'd as short, and Pure-C would just push a short even when passing a long as argument.

Btw, that parameter is nowhere actually used, neither in Magic nor in mint, and the initial prototype is just broken.

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Fri Sep 06, 2019 7:29 am

Hi Thorsten,

hat is the case on MiNT IIRC, but need not be. I think in MagiC it points to some internal structure. Just treat it as an opaque type that you pass along when calling functions.

Ah OK, pity as MagicPC is the only env where I have a decent debugger...
However, header on Aranym looks bad as well:
SLB Header dump 238a4:
magic =$29260 (INcorrect)
name =p
version =$10167
flags =$3BC80000
num_funcs =0

How is SLB_NARGS defined?

Well, I just copy/paste your own code :-):
#undef SLB_NARGS
#if defined(__MSHORT__) || defined(__PUREC__)
#define SLB_NARGS(_nargs) 0, _nargs
#else
#define SLB_NARGS(_nargs) _nargs
#endif
So yes on PureC, it expands to 0, _nargs

I'm about to think there might be an issue with PureC here, it looks like cdecl is ignored as the result is the same with:
typedef long cdecl (*SLB_EXEC)(SHARED_LIB sl, long fn, short nargs, ... ) ;
and:
typedef long (*SLB_EXEC)(void , ... ) ;

The weird thing is that it works for ordinal 1 on Aranym even if header looks wrong, either it seems that output parameter sl in Slbopen is wrong.
However, fn looks good as assembly code at returned pointer is (see picture) on MagicPC:
MOVEA.L 4(A7),A0 ; A0=SLB handle
MOVEA.L 4(A0),A0 ; why this double indirection ?
MOVEA.L 8(A7),D0 ; D0=function ordinalslbexec.S
CMP.L $44(A0),D0 ; Compare with maximum number of functions

pretty similar to __slb_local_exec in zview code at: https://github.com/th-otto/zview/blob/9 ... /slbexec.S
except the double indirection

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 750
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Fri Sep 06, 2019 9:16 am

JeanMars wrote:I'm about to think there might be an issue with PureC here, it looks like cdecl is ignored as the result is the same with:
typedef long cdecl (*SLB_EXEC)(SHARED_LIB sl, long fn, short nargs, ... ) ;
and:
typedef long (*SLB_EXEC)(void , ... ) ;


Generally, it should work. There are only two issues maybe:
- you must not use "ANSI keywords only" (but in that case you will get a compile error when using cdecl)
- you should check that "cdecl" isn't defined to empty somewhere else. My guess is that this is the case.

typedef long (*SLB_EXEC)(void , ... ) ;


That should give the same result for Pure-C (provided you pass the correct types, since no further checking possible). However, that syntax is actually not valid, you have to have at least one fixed parameter when using "...", and GNU-C rejects this, so i'm not using it.

MOVEA.L 4(A0),A0 ; why this double indirection ?


I cannot tell for sure about MagicPC, but if the kernel is based on the same sources as Magic: the handle you get back from Slbopen points to some internal structure, not directly to the SLB header. see https://github.com/th-otto/MagicMac/blo ... #L200-L204

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Fri Sep 06, 2019 10:33 am

Hi,

Generally, it should work. There are only two issues maybe:
- you must not use "ANSI keywords only" (but in that case you will get a compile error when using cdecl)
- you should check that "cdecl" isn't defined to empty somewhere else. My guess is that this is the case.

ANSI keywords only: for sure not
cdecl is only defined to empty in portab.h:
#if DR_C | LASER_C | LATTICE_C | MW_C | HIGH_C | PCC
#define cdecl
#define pascal
#endif
But:
- I'm not including it in this module,
- the #if conditions won't match
- cdecl is working OK with LDG calls used in the same module

What I'll check is how such a call is made at assembly level:
status = ImgModule->SlbExec( ImgModule->hLib, 8L, SLB_NARGS(1), (long)which );
If ImgModule->hLib, 8L, SLB_NARGS(1), (long)which are passed through stack or using A0/A1/D0/D1 registers.
But in case registers are used, I've no clue how to work this out.

And also I can't explain how ordinal 8L works on Aranym as hLib looks wrong. You sure SLB lib handle on Aranym is a pointer to a SLB_HEADER structure?

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 750
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Fri Sep 06, 2019 1:58 pm

JeanMars wrote:What I'll check is how such a call is made at assembly level:


Simple test:

Code: Select all

#define SLB_NARGS(_nargs) 0, _nargs

typedef void* SHARED_LIB;
typedef long cdecl (*SLB_EXEC)(SHARED_LIB sl, long fn, short nargs, ... );

typedef struct {
   char something[80];
   void *hLib;
   SLB_EXEC SlbExec;
} ImgModule;

void test(ImgModule *img_module, void *name, void *info)
{
   img_module->SlbExec(img_module->hLib, 1L, SLB_NARGS(2), name, info);
}


Code: Select all

dispobj test.o -v
test:
T000000:   MOVE.L    A2,-(A7)
T000002:   MOVEA.L   A0,A2
T000004:   MOVE.L    $0008(A7),-(A7)
T000008:   MOVE.L    A1,-(A7)
T00000A:   MOVEQ.L   #$02,D0
T00000C:   MOVE.W    D0,-(A7)
T00000E:   CLR.W     -(A7)
T000010:   MOVEQ.L   #$01,D1
T000012:   MOVE.L    D1,-(A7)
T000014:   MOVE.L    $0050(A2),-(A7)
T000018:   MOVEA.L   $0054(A2),A0
T00001C:   JSR       (A0)
T00001E:   LEA.L     $0014(A7),A7
T000022:   MOVEA.L   (A7)+,A2
T000024:   RTS



You should see that all parameters to SlbExec are pushed to the stack.

And also I can't explain how ordinal 8L works on Aranym as hLib looks wrong. You sure SLB lib handle on Aranym is a pointer to a SLB_HEADER structure?


Yes, thats a bit strange. And no, i was not sure (when you mean MiNT when speaking about Aranym, Aranym is not involved in that). In fact, it isn't. It is similar to MagiC, and the hLib points to this structure. The exec routine is defined here

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Fri Sep 06, 2019 2:47 pm

Hi Thorsten,

thanks for this check, I'll check on my side when free.
And yes, confused Aranym with Mint :-(

Cheers,
Jean

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 750
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sat Sep 07, 2019 6:45 pm

JeanMars wrote:Full source code is available at http://vision.atari.org/download/temp/srcvis.zip


I tried to compile that source, and had some sever problems with it. First off, there are 2 different version of xaes.h, with different declarations of GEMPARBLK. That is calling for trouble, since it must match the definitions used to compile PCGEMLIB.LIB. Which version of pcgemlib.lib are you using?

Secondly, none of these header files worked. They attempt to replace aes.h, but fail to declare for example the USERBLK structure. Using the original aes.h does not work either, because it is missing the MultiTOS definitions. So my suggestion is:

- put xaes.h, xvdi.h, portab,h, ldg.h etc. to some separate directory, and add that to the include directories in the project file.

- either include the original aes.h in xaes.h, and add only the missing definitions there, or rewrite xaes.h to be a really complete replacement.

- using wind_get()/wind_set() with the original binding from pcgemlib.lib will not work well for constants like WF_ICONIFY. That binding uses a table to look up the number of input parameters, but does not know about the multitos/mint specific constants.

Since the original pcgemlib.lib is rather incomplete nowadays, i use the latter approach in my own projects, ie. use a complete replacement, both for the header files and the libraries. They are available as part of magicmac if you want to have a look.

Edit: i also noticed that there is a pcfltlib.lib in your archive. Is that patched somehow?

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Sat Sep 07, 2019 8:02 pm

Hi Thorsten,

Thanks for pointing this out, it is true that vision was developed in early 90s and a refresh of include/lib would definitively be a good idea.
Not sure why there are 2 xaes.h in the backup but the one used to compile is the one in tools folder.
Can't look at this now but afair iconify is working with. Vision in mint and magic and tos 4.92.
Yes pcfltlib has.been patched decades ago to be compliant with magicmac or pc, there is a bug entry for this in vision bug's page.
I'll look into this when back at home.
Thanks again,
Jean

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Sat Sep 07, 2019 8:04 pm

Btw to.compile vision, did you use the original purec include and libs?

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 750
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sat Sep 07, 2019 9:11 pm

Yes, i did some patches now (attached below), and used the original includes and libraries. No crashes here in Aranym. However, there is also a zip in your archive with a compiled version, that does not crash either ;) So i think there must be some mismatch between pnglib16.lib and pnglib16.slb in your installation.

Don't be shocked by the size of the patch, most of it results from moving header files around, so in the diff their whole contents appears twice. Short overview: removed xaes from the top level folder. Moved tools/xaes.h, tools/xvdi.h, tools/xalloc.h, tools/logging.h, tools/xgem.h, tools/portab.h (renamed to xportab.h) and tools/stdinput.h to include folder. Then changed xaes.h as mentioned above. The remaining patches are then mostly changes to the include statements.

PS.: i also noticed that the popup in the menu seems to require magic/wdialog.

Edit.: ok i just realized that in my first tests, it did not use the zvpng.slb module at all (i had to edit the vision.ini unless i missed something). However, even with that path now found, it seems not to be be used:

Code: Select all

07/09/19 22:48:44 [DEBUG] FolderExist(H:\atari\zview\zview\tests)=1
07/09/19 22:48:44 [DEBUG] FolderExist(C:\)=1
07/09/19 22:48:44 [DEBUG] FolderExist(C:\SRC\VISION\VISION\DSP)=1
07/09/19 22:48:44 [DEBUG] FolderExist(C:\SRC\VISION\VISION\LANGUES)=1
07/09/19 22:48:44 [DEBUG] FolderExist(C:\SRC\VISION\VISION\TEMP)=1
07/09/19 22:48:44 [DEBUG] FolderExist(C:\SRC\VISION\VISION\FILTRES)=1
07/09/19 22:48:44 [DEBUG] FolderExist(C:\SRC\VISION\VISION\LDV)=1
07/09/19 22:48:44 [INFO]  zView LDG path  does not exist, VISION won't use any zView LDG plugin
07/09/19 22:48:44 [DEBUG] FolderExist(H:\atari\zview\zview\codecs)=1
07/09/19 22:48:44 [INFO]  CPU:68040, FPU:68040, DSP:<None>
07/09/19 22:48:44 [INFO]  Language:ENGLISH
07/09/19 22:48:44 [INFO]  Loading RSC file C:\SRC\VISION\VISION\LANGUES\ENGLISH\VISION.RSC with rsrc_choice=-1
07/09/19 22:48:44 [DEBUG] appl_getinfo ret=1, a3=1, a4=1, SVersion:4000
07/09/19 22:48:44 [INFO]  Xrsrc_load: using xrsrc_load
07/09/19 22:48:44 [INFO]  Image module priorities: 13
07/09/19 22:48:44 [DEBUG] No path for dynamic modules VISION
07/09/19 22:48:44 [DEBUG] Loading dynamic modules zView LDG from path ...
07/09/19 22:48:44 [DEBUG] Loading dynamic modules zView SLB from path H:\atari\zview\zview\codecs...
07/09/19 22:48:44 [IMG]   48 modules of type zView SLB found in H:\atari\zview\zview\codecs
...
07/09/19 22:48:44 [DEBUG] New module ZVPNG.SLB (type zView SLB) found
07/09/19 22:48:44 [DEBUG] Module already registered
...
07/09/19 22:48:44 [IMG]     #1
07/09/19 22:48:44 [IMG]     File:             
07/09/19 22:48:44 [IMG]     Type:             1 (VISION module)
07/09/19 22:48:44 [IMG]     Dynamic:          No
07/09/19 22:48:44 [IMG]     IID:              PNG ($504e4700)
07/09/19 22:48:44 [IMG]     Name:             Portable Network Graphics
07/09/19 22:48:44 [IMG]     Version:          01.01
07/09/19 22:48:44 [IMG]     Known extensions: PNG


I guess i have to give it a different priority, but how?

I tried

Code: Select all

[Img Priorities]
Global = 3,1


But it still seems to use the internal module only.

Edit2:
Ok using

Code: Select all

Global = 3


worked, but i guess this is not how it was intended...

Now i get the crash, too. Trying to figure out, why...
You do not have the required permissions to view the files attached to this post.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 750
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sun Sep 08, 2019 5:22 am

Ok, got it. There was one important point missing (maybe because of lack of documentation :angel: ) : the plugins need callbacks to the applications library. In zView, that was implemented in zvplugin.c. For vision, i've implemented it now in iizview.c, see attached patch file. I've also added calls to retrieve the plugin version number (a feature added a few days ago; it's not the same as the SLB version number). Also the zview specific structures are now moved to tools/zview, and are now identical to the ones used by zview itself, so it should be easier to update them if needed.

Some minor changes: i've changed the project file to use slb.s instead of slb.c. It's maybe not strictly necessary, but the generic gemdos function is not reentrant, which might cause trouble with MagiC. Also replaced direct calls to Slbopen() by slb_load() (which is already part of the import libraries), so it should theoretically also work with SingleTOS.

Things that don't work yet: the zvtiff.slb and zvjpg plugin. This is because the tiff library was compiled with default settings, which includes lzma compression, and i don't have an import library for Pure-C yet (i hope i can fix that soon). Similarly, the jpeg plugin needs exif.slb to extract meta-information. As a result, those plugins can be loaded, but not initialized (the plugin_init function in vision is void, although it was supposed to return an error code).

Large parts of the changes were copied from zView and/or the sharedlibs, so if they don't match your indentation style, feel free to change it ;)

The interface recently got 3 new functions, to convert international (utf-8 or ucs16) text to atari encoding. But if i didn't overlook something, those functions are not yet called by vision. If you ever do, you must also initialize the txt_data structure that is passed to the codecs (this is also needed for LDG plugins).
You do not have the required permissions to view the files attached to this post.

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Sun Sep 08, 2019 8:08 am

Hi Thorsten

Well great job :D
Why using callbavks for mem... functions? Save some code room in module?
Should be able.to work a bit on this this evening.
Again thanks for the time you spent on this!

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 750
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sun Sep 08, 2019 10:07 am

Yes, not only some room, but quite a lot. Previously, when compiled by gcc, each plugin had half of the mintlib statically linked, thats why they all were ~100k. But more importantly, that also means that each module maintains its own malloc heap, and other static variables. That would not work if it is really used by more than one application, and thats also the main reason why LDGs cannot be shared. And its not only the mintlib, zlib was also used by png, pdf, freetype etc. All those libraries are now loaded only once, by the main application. Still that app shrunk from ~1.7MB to ~400k.

PS.: i was not sure what is easier for you to use, so i created patch files. If you need the complete updated source archive instead, let me know.

OL
Atari Super Hero
Atari Super Hero
Posts: 503
Joined: Fri Apr 01, 2005 6:59 am
Contact:

Re: SLB 'devkit' ?

Postby OL » Sun Sep 08, 2019 1:22 pm

ThorstenOtto wrote:Yes, not only some room, but quite a lot. Previously, when compiled by gcc, each plugin had half of the mintlib statically linked, thats why they all were ~100k. But more importantly, that also means that each module maintains its own malloc heap, and other static variables. That would not work if it is really used by more than one application, and thats also the main reason why LDGs cannot be shared. And its not only the mintlib, zlib was also used by png, pdf, freetype etc. All those libraries are now loaded only once, by the main application. Still that app shrunk from ~1.7MB to ~400k.

PS.: i was not sure what is easier for you to use, so i created patch files. If you need the complete updated source archive instead, let me know.


Using libc as it is LDG can't share, each lib should manage memory by itself or use mem.ldg that is supposed to fix this (supposed for me because I have not tested it) it use shm to share memory I don't know really if it ok or not, my point of view when possible each lib should have isolated memory for each application. For sure not easy.
OL

vido
Atari Super Hero
Atari Super Hero
Posts: 693
Joined: Mon Jan 31, 2011 7:39 pm

Re: SLB 'devkit' ?

Postby vido » Sun Sep 08, 2019 2:18 pm

How much work/hard would be to adapt sources that Vision would be compilable with the gcc?
I am asking this because native coldfire version for the Vision would be really great!

JeanMars
Captain Atari
Captain Atari
Posts: 155
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Sun Sep 08, 2019 5:05 pm

Hi,

@Thorsten: I had a quick look at the modifications you made, 2 comments:
- Yes please I would prefer to have a ZIP containing all updated source archive
- I see many static dependencies in new sources regarding jpg, png and tiff for new SLB format. Why this? The caller should not be aware of this, does that mean that every time a new dynamic module is added, VIsion/zView has to be modified to be aware? This is not the case for LDG ones.

@vido:
How much work/hard would be to adapt sources that Vision would be compilable with the gcc?
I am asking this because native coldfire version for the Vision would be really great!

A LOT:
First a remark: VISION has been designed in early 90s with 1 big requirement and an assumption:
- Be fast, so use 680x0 code when it comes to CPU intensive stuff such as bitplane to index conversions, bitpmap zooms, LZW inflate/deflate, etc.
- Do not consider portability, i.e. an int is always 16bit, quite a crazy assumption nowadays...
So to be gcc compliant:
- rework all files to deal with int vs WORD
- for Coldfire, it would be even MUCH worse as all 68000 and 68020 routines would have to be ported to C.. And there are tons of these...


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 1 guest