[Freemint-list] Gemma

[Thorsten Otto]

On Sonntag, 30. April 2017 14:45:17 CEST Vincent Rivière wrote:
> Does anyone managed to get any success with Gemma?

While looking at all the compiler warnings when trying to compile the 
libraries, i took a look again at those sources. There are a few quirks that i 
found:

- despite there name (gemma32 and kernel32), i think you have to compile at 
least the tools using it (gemkfatfs in this case) with -mshort. The reason is 
that the entry points in kernel.h and gemma.h are all called like this:

return (gemma_p->exec)(gemma_p->handle, (long)RSRC_XGADDR, (short)2, type, 
obj);
return (gemma_p->exec)(gemma_p->handle, (long)RSRC_XLOAD, (short)1, file);

etc. When compiled without -mshort, this will promote the arguments to int, no 
matter how hard you try to cast them (same symptom as when calling GEMDOS 
traps). So that source just does not seem to be ready for 32-bit ints.

- the exec function (returned from the Slbopen call) is defined as

long (*exec)(void *handle, long fn, short nargs, ...)

Since the number of args is variable, this must be passed along with the call, 
so the kernel implementation knows how many arguments to copy. However the 
name "nargs" is misleading, it must be the number of short ints that make up 
the additional arguments. Both MagiC and MiNT really depend on this to be 
correct. But the calls are made like this:

	return (gemma_p->exec)(gemma_p->handle, (long)RSRC_XLOAD, (short)1, file);

Here "file" is a char *, thus nargs should be 2, not 1.

- If i understood the codeflow correctly, "kernel32.slb" is loaded by 
gemma32.slb. At least MiNT currently does not support loading one slb from 
another.

- due to the binutils producing an extra header behind the gemdos header, the 
linked slb's will only be loadable by MiNT. The necessary patch for this was 
added in 20011/08/11, so any earlier version of MiNT will not be able to load 
it. Same problem for MagiC, which will not be able to load them without 
removing that header.

The problem with the source of kernel32.slb not being available could be 
solved by
- reimplementing it (there are not many functions that gemma needs).
- getting rid of that dependency completely, and use the normal gemdos calls 
instead.