Font_read_defn

[Chris Johnson]

In article <ec5b3b4f4a.Tony at mk-net.demon.co.uk>,
   Tony van der Hoff <tony at mk-net.demon.co.uk> wrote:
> In message <4a4ed8f0d3chris at bulldog.u-net.com>
>           Chris Johnson <chris at bulldog.u-net.com> wrote:

> > I have been converting my old BASIC apps to C/oslib. I have hit a
> > problem with the routine to deal with fonts at a mode change. I have
> > isolated the problem to the oslib function
> > 
> >         font_read_defn
> > 
> > Every time it is called (whether an actual mode change or not) it
> > causes a fatal exit due to a "no stack for trap handler" error.

> [snip]
> > 
> > In the original BASIC program I simply called SYS "Font_ReadDefn", but
> > that requires a pointer to a buffer (for font identifier) to be passed in
> > R1. There is no evidence of this in the oslib version.
> > 
> Yes, that is correct. The OSLib call font_read_defn() does not return the
> font identifier; you need font_read_identifier() for that.

> > The other odd thing is that if I use DDT and single step through the
> > program, the error is not raised.
> > 
> Well, your code snippet looks OK, but OSLib's implementation of that SWI
> looks fine too; this probably means you need to be looking at your
> runtime environment when the call is made. Basic and DDT isolate you
> from some of the problems here by setting up their own environment. 

> How are you calling that function? If it's as a result of a service call
> (which you shouldn't intercept in an absolute application in any case),
> the processor may be in SVC mode, and you may not have a SVC stack.

> You could try using the x-version of the SWI, and handling any error
> return yourself, thus avoiding the trap handler.

Thanks - I thought I would check that there were no known problems with
the oslib implementation of font_read_defn.

The call would normally be part of a function called in response to the
wimp message mode changed, but I have tried calling the skeleton function
with just the font_read_defn call in it at various points in the program,
in response to a menu selection for example, and it crashes out every time.

I will have to implement much fuller error reporting to try to identify
the problem.

Chris...

-- 
CHRIS JOHNSON                     mailto:C.A.Johnson at hw.ac.uk     (work)
                                  mailto:chris at bulldog.u-net.com  (home)